I think I better understand now - you want 'other' tabs to dynamically update (without the user hitting Refresh) if the user changed namespaces in a separate tab, is that correct?

I think there are probably Javascript events that fire when a tab comes back into focus (you'd have to check) and you could use those to trigger a call to the server to see if the namespace has changed - if it has then redraw the tab to show the context of the proper namespace.  It would have more moving parts but it should be possible if you really want to do it.

Good luck!

Laura,

Unless you are using web sockets, whenever someone makes a request from a web client it will issue a call back to the Caché server and it will be handled by a csp process which will spin up and go to a namespace and get the appropriate session variables, etc.  If I understand properly what you are looking to do, you could store the namespace as a session variable and then on each of your pages you can test the session variable on the request and reset to a different namespace if it isn't the default.  I believe that this is how the SMP does it (or something very similar).

HTH,

Ben

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?