Rather than setting the global, could just Do $SYSTEM.Version.SystemMode(newMode) where newMode is LIVE, TEST, FAILOVER, or DEVELOPMENT (case-insensitive).
From my experience, foreign keys are really underrated/underused among ObjectScript developers. With relationships you don't need to worry about them, but really any time you have an object-valued property (not a relationship) there should almost certainly be a foreign key defined on it. (Same thing goes of course for non-object references to uniquely identifying fields in other tables.)
I'm currently looking in to this and hope to have it fixed in short order. Thank you for letting us know. We apologize for the inconvenience and will let you know once the issue has been addressed.
I already use this approach as much as possible, both for the applications I develop and my Open Exchange projects. It makes it easy to trace from test to tested unit, and (in the community package manager world) it avoids collisions between different packages all trying to use the same unit test package. I strongly agree with Evgeny's recommendation.
Ahh... looks like that's just in IRIS (2018.1+)
Rather than setting the global, could just Do $SYSTEM.Version.SystemMode(newMode) where newMode is LIVE, TEST, FAILOVER, or DEVELOPMENT (case-insensitive).
re: "creative minds" - been there, done that, should probably put it on the Open Exchange at some point... ;)
From my experience, foreign keys are really underrated/underused among ObjectScript developers. With relationships you don't need to worry about them, but really any time you have an object-valued property (not a relationship) there should almost certainly be a foreign key defined on it. (Same thing goes of course for non-object references to uniquely identifying fields in other tables.)
Neat - I'm looking at EnsLogViewer and it seems like the "MultiType" class query is a good example of this. https://github.com/intersystems-ru/EnsLogViewer/blob/master/EnsPortal/Ev...
I'm currently looking in to this and hope to have it fixed in short order. Thank you for letting us know. We apologize for the inconvenience and will let you know once the issue has been addressed.
@Azezur Rahman - I'd appreciate if you could confirm that everything is working properly for you now.
This issue has been resolved. Thank you again for notifying us.
Code Snippets do part of the job; for other things (e.g., SOAP Wizard), see @Patrick Newton 's comment on https://github.com/intersystems-community/vscode-objectscript/issues/325 - there is planned support for these.
I already use this approach as much as possible, both for the applications I develop and my Open Exchange projects. It makes it easy to trace from test to tested unit, and (in the community package manager world) it avoids collisions between different packages all trying to use the same unit test package. I strongly agree with Evgeny's recommendation.