First - welcome to the InterSystems Developer Community and to exploring InterSystems database technologies!

I see that you changed your original post and content and changed it to ask about the cube (original post was "question I want to use the database in the evaluation version").  I think it might be easier for you if I try to answer your first question ;)

My suggestion is that if you are new with InterSystems technologies that you start with InterSystems IRIS rather than Caché.  There are some great cloud-based trials for exploring and learning about InterSystems IRIS and you don't have to install anything locally in order to play with it.  

Please check out: https://www.intersystems.com/learn-play/

If you would prefer to play with Caché locally, then I am sure someone can answer your question about the cube (I am not on a Mac so I can't advise on that point).

All the best!


Unfortunately "ATL-3982" is not included.  I don't know anything beyond that (in terms of plans for it in the future).  You may want to grab a Product Manager to discuss if you're going to Global Summit in a couple of weeks.  

Bravo!!  I had never really seen a good 40,000 foot view of machine learning before, and this really suits the need!!

Thanks for your work on this Don!

Eduard - I think Arcady was asking from a purely data-processing perspective.  I.e. if you are already have a bunch of in-memory data and need to process/iterate on it, is it better to stick it in traditional structures and use $Order, or is it equivalent to stick it into the new structures for iterating and processing?  I think it's a good question and I would also like to hear what people think :)


Thank you very much for the working sample - I really appreciate it!!  In the end I decided to go with the approach of just projecting the property from the container into the embedded obj because it ended up being better for my particular project.  If I have to revisit this in the future because I need more than just that one property, I will definitely try out your example!

Thanks again,


Thank you all ... sometimes all it takes is a good night sleep :)

I figured out to avoid recursively updating the value via the trigger .... don't update it if I don't need to :)

Here is my code - it now works like a charm!

Trigger TUpdateFoobar [ Event = INSERT/UPDATE, Foreach = row/object, Time = AFTER ] 


    Try { 

      // get value of Foobar 

      NEW fb 

      SET fb= {Foobar} 

      // INSERT value into embedded foobar, *only* if it differs from Container value

      If (fb'={InnerObj_Foobar}) {   

        &sql(UPDATE ContainerObj (InnerObj_Foobar) 

            VALUES (:fb) 

            WHERE %ID=:{ID})           


    } Catch tError {             

      Do LOG^%ETN             

      Throw tError        



I have been trying this approach but I am hitting a wall. It appears that because I am inserting the value into the embedded object in the container, it is seeing this as an additional UPDATE and calling the TRIGGER again, resulting in a <FRAMESTACK>.  Any ideas on how to prevent the <FRAMESTACK> error? 

Here is my simplified code:

Trigger TUpdateFoobar [ Event = INSERT/UPDATE, Foreach = row/object, Time = AFTER ]
  Try {
    // get value of Foobar
    NEW fb
    SET fb= {Foobar}

    // INSERT value into embedded Primary Environments
    &sql(UPDATE ContainerObj (InnerObj_Foobar)
     VALUES (:fb)
     WHERE %ID=:{ID})

Catch tError {
Throw tError

thank you for the time you took to look!  I thought that UPDATE SQL rights might be sufficient.

Thanks again and have a great night!

Agreed - this could be very dangerous if not used carefully.  Fortunately in my case it's a training VM where all users are created programmatically :)

Do you have any idea on the minimum privileges required to select or update the Security.User table?

Thanks again for your help!

This is for an exercise I'm creating for updating users via SQL.  It is for educational purposes only and isn't going to be anything used in production