AllAccepted answers
Ben Spead · Aug 15, 2018

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 :)

Ben Spead · Jun 17, 2018

Vitaliy,

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,

Ben

Ben Spead · Jun 17, 2018

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        

    }

  }
Ben Spead · Jun 16, 2018

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 {
Do LOG^%ETN
Throw tError
}
}
Ben Spead · Apr 25, 2018

Also, Classes lend themselves much better to programmatic access and manipulation of their content (you can do this with routines too but it is harder to do so due to their unstructured nature).

For example, the server-side Source Control hooks we use can programmatically insert an RCS Keyword as a class parameter ("SrcVer") into any class which doesn't already have it defined.   This is extremely powerful because it allows source control to create an automatic 'watermark' in every class created for our internal applications which can be programmatically access or from terminal:

SSO>write ##class(AppS.WebClient).#SrcVer
$Id: //custom_ccrs/us/ISCX/SSO/BASE/cls/AppS/WebClient.xml#6 $

This would require much more plumbing to do automatically with a routine!