Here is a possible cause of the 404 error:

An IRIS REST service [or Cache REST service] supports the OPTIONS request (the CORS preflight request – used to determine whether a REST service supports CORS). This request is executed by the CSPSystem user. This user should have READ permission on any databases used by the REST service; if not, the service will respond with an HTTP 404 error.

I believe the preferred option is the DependsOn class keyword.  We use this often in DeepSee, because whenever you recompile the base class on which you base your cube, you should also recompile the cube class. So the cube class  looks like this, for example:

Class DeepSee.Model.PatientsCube Extends %DeepSee.CubeDefinition [ DependsOn = DeepSee.Study.Patient ]


Hi Kevin,

We're certainly considering things like that. We have to work out how to apply & remember such filtering not only to search but also to browsing. We can't make any promises about dates, though, especially because we are also working on how to search across other repositories of information (such as the class reference and samples).

For now, if you have Cache (but not Ensemble) installed, you won't see the Ensemble doc. anyway, so hopefully that takes care of the concern you mention here. I hope this helps you.

No, we did not use iFind. Primarily we exploited what we already know.

The filtering options (product, book, and tag) take advantage of our pre-existing knowledge of our content. (There is no reason for us to try to deduce what we already know.)

Likewise, the overall ranking takes advantage of our pre-existing knowledge of which books are central and which are more peripheral. (All other things being equal, you ought to see search results from Using Cache Objects before you see results from the MSM to Cache Conversion Guide, right?)

The other key change, in my view, is that we added search options that look at every single character of your search text. The previous search ignored non-alphanumeric characters other than & and %, thus making it difficult or impossible to search for many technical terms (like .obj for example!).

But iFind could be helpful at some point, as an option. I suspect strongly that it would be a useful option for some kinds of searches but not for others. iFind provides the ability to find related items. We examined about 3000 past searches at and found that the majority of them were searches for specific technical items (wd buffer size, $listbuild, %openid, <STORE>, and so on), many of which already have very large numbers of results. It's not yet clear whether it would help to display items "related" to those items.

Year->Month->Day is actually not a valid DeepSee hierarchy. Consider this: Which year does "January" belong to? Which month does the 17th day belong to? These questions have no answer.

But Year->MonthYear->DayMonthYear *is* a valid DeepSee hierarchy. In this hierarchy, the second level has members such as 2016-January, which does belong to a specific year.

I find it useful to bear in mind two points:
1) A member is a set of records.
2) DeepSee hierarchies are parent-child hierarchies. That is, all records that belong to a given member also belong to the parent of that member.