Matthew,

See https://community.intersystems.com/post/writing-forward-compatible-json… to allow you to write code that will work on both 2016.1 and 2016.2.  This is the approach we're using internally to write code that is valid in both versions which has already minimizes our pain.  I hope it is helpful to you.

I have "On Updates" and "On Comments" checkboxes on that page for all of my subscriptions.  Perhaps because I am signed up for individual emails (which may have more subscription options) and you are signed up for a Digest? (or perhaps maybe not - I tried changing to Digest and still see the "On Updates" checkboxes.

I think a Community Admin needs to weigh in because I don't know why your settings are different.

I apologize - I thought it was possible to add Tags to Answers, but I guess not.  The Code Sample tag would need to be added by Marc to the original question.

Bravo! Make sure to tag this as "Code Sample" so people can find it easily in the future

If you look at the %Library.File:FileSet() query and the %Library.File:Delete() method I think you could probably convert this to an OS-independent solution in about 10 min or less :)  Just sort the FileSet() query results by DateCreated and then stop processing the files once you get to the cutoff date for what you want to keep :) 

Thanks Rob - all very interesting stuff :)  I'll leave it to Product Management to weigh in on the server-side JS.

Thanks Stefan. All interesting points.

Can you build bitmap indices against a specific property in a document container?   Do we have any data on the performance of large document datasets (using indices) as compared to large persistent tables of Caché objects?

In terms of storing complex values in a property - in actuality would there be any additional support for handing that same complex property as a piece of a document?  It seems to me that you need to do all of your own handling code in all cases if you use documents.  I guess an advantage would be the ability to subindex pieces of a document (I assune that is supported or soon will be?)

Thanks for the details on the documenting of the schema's.  I was guessing it was something along those lines - again sort of a throw-back to keeping separate global structure documents in legacy Caché.  Not a deal breaker but it takes a higher level of discipline in order to keep the code maintainable as it evolves over time.

I learned a lot from this thread - thanks!

Stefan,

Thanks for your thoughtful response.  A few comments and questions on your clarifications:

• Flexibility
  • I am certain there are some more extreme situations where migration is necessary but the majority of my experience has been around data evolution with Caché Persistent Objects which is trivial to achieve (even renaming a field is straightforward without moving any data).  But if someone has to do a massive data migration moving data from one set of objects to a refactored set of objects then there is certainly some work involved.  
• Sparseness
  • Your point about the $lb performance is interesting.  I did some quick tests and it looks like looping over a $lb structure 10M times to add 2 elements in the 1st and 2nd positions sees a 40% increase when accessing the 1st and 20th position and a 270% increase when accessing the 1st and 60th position.  So there is something to be said about the hit for extremely sparse persistent objects that are being referenced many, many, many times in succession (even my 60th position test only took 1.9 sec to access the two elements 10M times).  In reality I am not sure about what type of data model would actually run into this type of consideration (that and the need to be concerned about the tiny waste of space for null placeholders in a sparse $listbuild).  But it is an interesting thing to think about
• Hierarchical
  • Your statement about objections only being able to store an embedded object is not entirely correct.  One of the advantages of the Parent/Child relationship is that the children are colocated in the storage of the parent.  This has major performance implications (just like serial objects) and are a very powerful construct as a result.  The only places where you are not colocating the data are the one to many or if you have a linked class instance.  With a complex data model you would certainly have fewer reads with a document store.
• Dynamic Types
  • Your example isn't quick accurate - since Caché stores everything as a string you can give yourself as much flexibility as you want by not using a constrained type when designing your object.  You could use name as a %String in a persistent Caché object and then store either the value of "Stefan Wittmann" or the value of "{'first':'Stefan','last':'Wittmann','middle':null}" :)  You have full flexibility if you choose to have it - or you can use typing to leverage the build-in validation.  

From my perspective, while there is certainly increased flexibility to be gained with documents, that comes at the pricing of having to write more validation and processing code.  In addition, Caché Persistent Objects make it very easy to have your schema and structure be self-documenting (and the class definition can be the 'source of truth').  With Document, which in many respects is a move back in the direction of 'roll your own global structures' the developer would be on the hook for creating external documentation on the structure and field uses of the documents that are stored in the container.  Certainly picking good property names is a good step in the right direction, but that doesn't get you are far as you can get with class and property comments in a persistent class definition.  How do you envision people documenting their document schema?  

Thanks for pointing that out John!  That hasn't crossed  my radar yet and I am especially glad to see it as well!

Take a look at the $system.OBJ.Load() and $system.OBJ.LoadDir() methods.  This is the most common way to take source from your source control system and load them into your namespace.  

you are most welcome!!

Yes - if you New $namespace, then once the context pops off the stack it will revert automatically to the original namespace before setting the newed version of $namespace

Timur - THANK YOU!  It hadn't gotten annoying enough to google a solution yet, and you just saved me the effort :)