New post
AllAccepted answers
Ben Spead · Nov 10, 2018

You can use $version(1) to see if it is Windows (returns '2') or UNIX (returns '3').  If you want to get really fancy you can include %occOptions.inc and then use the $$$isUNIX and $$$isWINDOWS calls (which just check to see if $version(1) is 2 or 3).

Personally, I like using ##class(%Studio.SourceControl.ISC).RunCmd() as it wraps the capture of the output for parsing.

You can tie $version together the other answers into something that is platform independent (warning, I haven't tested this, but I believe the pieces work):

If ($version(1)=2) {

   //Is Windows

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("Ver",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

} elseif ($version(1)=3) {

   //Is UNIX

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("uname -a",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

}
Hope that helps you Paul!
Ben Spead · Nov 2, 2018

Mack-  the %occLibrary calls are not documented for use by applications.

As  your very interesting questions has proven the  ease with which this is solved by:

$$CSVtoList^%occLibrary(csv)

I suggest you contact the WRC to request an enhancement to have this wrapped in a supported (and documented!) API that may be more future-proof than this internal and undocumented call.

Ben Spead · Oct 17, 2018

Daniel,

You are absolutely correct that using Client-Side source control hooks (ie the Eclipse Git hooks with Atelier) in a Shared development instance is a recipe for disaster and frustration.  You options are moving to Private development environments (each developer gets their own Namespace, or instance, or VM or container), or move to Server-side source control hooks.

I did an in depth session on this at Global Summit 2017 which should be of interest to you.  You can watch the recording and get the slides here:

https://learning.intersystems.com/course/view.php?id=713

HTH,

Ben

Ben Spead · Sep 18, 2018

Akio,

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!

Ben

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
}
}