You should definitely store your storage schema in VCS. When you first compile and install your solution into an environment, it doesn't really matter -- as you said, storage will be generated automatically during compilation. However, this will cause major issues when you'll have to upgrade your environment to a newer version of your class and keep the data.

If you had a class definition in Version 1 of your system with properties Address, Zipcode your storage schema will look like

node=$LB($ClassName,Address,Zipcode)

If in version 2 you add another property, BusinessPhone, and you kept your schema, new storage definition will look like

node=$LB($ClassName,Address,Zipcode,BusinessPhone)

And all old data will still be valid, just its BusinessPhone property will be empty

However if you didn't save your schema, new storage will be alphabetically sorted as this:

node=$LB($ClassName,Address,BusinessPhone,ZipCode)

And all old data will have its ZipCode as BusinessPhone now!

I encountered this problem a couple of times, when class definition was exported before it was compiled (and storage schema was not updated), and it was not easy to fix: you need to iterate across the whole global and rewrite it, trying to guess if it's an old data or a new one.

Hope this helps

Sergei

I know it's not too difficult, just thought maybe there is an API call we can use which will do the job for us.

There are few concerns, like conversions you mentioned, duplicate properties, query order nodes, etc.

 

For example for string http://www.intersys.com/main.csp?a=b&QUERY=abc&QUERY=xyz data array would be

data("QUERY",1)="abc"
data("QUERY",1,"O")=2
data("QUERY",2)="xyz"
data("QUERY",2,"O")=3
data("a",1)="b"
data("a",1,"O")=1

All subscripts will be calculated before merge command will start global merge, so looks like you hit this command several (at least 2) times within a second. Since you don't have $JOB as a subscript or data node it also could be that it's done from different processes.

On the other hand, it's considered a good code practice to assign $h to a variable somewhere at the top of the method, and use that variable instead of $h throughout the code.

Consider this code for example:

if (DAYNUM-$H>0) && (WKS>2) do ....
if (DAYNUM-$H<=0) && (WKS>2) do ....

You want to check if date is in future and do something different if it is. You would expect that only one branch of code would ever run; however in extremely rare circumstances when this code runs around midnight $h could change between first and second if statements and run both code branches, screwing up your database unpredictably.

Another good practice is to pass "current date" as method argument instead of assigning $h inside a method. This way it's much easier to test methods.

Hi Kenneth, 

There is $toJSON method which you can use to convert any persistent object into JSON. Actually any %Registered object has it too!

SAMPLES>set Person=##class(Sample.Person).%OpenId(1)

SAMPLES>set personJson=Person.$toJSON()

SAMPLES>write personJson
{"$CLASSNAME":"Sample.Person","$REFERENCE":"1","Age":65,"DOB":39985,"FavoriteColors":["Yellow"],"Home":{"City":"Fargo","State":"NC","Street":"7424 Main Avenue","Zip":82189},"Name":"Novello,Olga I.","Office":{"City":"Pueblo","State":"MT","Street":"430 Franklin Place","Zip":29528},"SSN":"315-46-7788"}
SAMPLES>w $zv
Cache for UNIX (Apple Mac OS X for x86-64) 2016.2 (Build 657U) Sun May 15 2016 20:35:24 EDT