Several of our doc. instances were broken for a couple of days. Root cause is that we had upgraded from an unreleased version to a later unreleased version. We're going to try not to do that again. 

Also see https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

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 also recommend looking at http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...  

select name from %Dictionary.CompiledClass where Super='yourclassnamehere'

You might also find this useful:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GORIENT_appx_whats_that

True. But also, if you recompile a set of classes (e.g., by compiling a package), then we look through for dependencies like this and make sure to compile the independent class before the dependent one.

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 ]

See http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ROBJ_class_dependson

Also remember to change

%AbstractObject to %Library.DynamicAbstractObject

!!!

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 docs.intersystems.com 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.

The doc. has an section on this:

" There are two kinds of methods in a class language: instance methods and class methods. These have different purposes and are used in different ways...."

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GORIENT_ch_classprog#GORIENT_classprog_method

I hope this helps.

On a related note, here is a useful appendix that you can use to figure out things like this:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

"As you read existing Caché ObjectScript code, you may encounter unfamiliar syntax forms. This appendix shows syntax forms in different groups, and it explains what they are and where to find more information."

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.

Is there some reason you can't directly use the class  EnsLib.HL7.Message?

This class has methods like ImportFromFile() and ImportFromString().

Scott, another comment, if I may...

The best practice, in routines, is to use curly braces to define procedure blocks and thus control scope, e.g.

selecttype() {

stuff

}

dataentry() {

stuff

}

FWIW, having looked at the internals of a lot of our classes and routines, I have hardly ever come across GOTO.

The doc. just recommends putting all of that on the server.  It doesn't say the four items need to be treated separately.

That said, some field experience would be useful!

It does not make sense that you would have to use curly braces here. I get the same results for your query with or without them.

But anyway, am glad you got the MDX you wanted.