IMHO this deserves an enhancement request. Data for mapped lib classes is stored in User Namespaces, but tune params for this data in Lib Namespace. Looks difficult to use persistent classes as part of a library in this case.
Maybe you can generate automatically the storage class @Eduard Lebedyuk mentioned with the first call from a User Namespace?
But why? "@" introduces an additional stack, right? And what is above in stack should be visible. Or not?
Wow. Confirm that for IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2019.1.0S
Hi David!
Great you've found the answer by yourself! It happens to me sometimes right after I end writing a question)
There is no need to add "Solved" to the title to indicate the question is closed. We have the feature of an accepted answer. So you can mark your answer as Accepted and this will be the indicator for the question as solved and it will disappear from the filter of Not accepted answers.
Thanks for your contribution!
Kyle! Really great staff!
This is also very helpful for DeepSee/IRIS Analytics projects, where you every time need to expand the access rules on yet another listing table.
Hi @Elize VdRiet !
Have you tried VSCode ObjectScript plugin already? It doesn't have a debugger (yet), but it's lite-weight and cross-platform and has some nice features for ObjectScript support.
Yes, understood. Maybe we need to allow this? But the idea is if Author of the question accepted the answer that means he doesn't want any new changes to it and wants to keep it.
Agree with @Eduard Lebedyuk answer, want to introduce another toolset:
1. Import ISC_DEV utility to a DEFAULT_INSTANCE say in a USER namespace and map the classes of the utility to %All.
2. Setup the workdir to export the code
YOURNAMESPACE> w ##class(dev.code).workdir("/path/to/your/wor
king/directory/")2. export code calling:
YOURNAMESPACE> w ##class(dev.code).export()
This will export cls, routines, and dfi (DeepSee) into separate files.
3. Create the repository in git and commit all the files from the directory into the repository (and even push, if you use Github/Gitlab)
4. Repeat p1-2 for a PRODUCTION_INSTANCE and export classes into the same directory.
5. Compare the changes. If you Open the directory in VSCode with Object_Script plugin by @Dmitry Maslennikov you will immediately see the changes in Source Control section of VSCode. E.g. I introduced one line and saved the class and it shows the files changed since the latest commit and the line with the change.
Alternatively you can commit and push changes to Github/Gitlub and see the diff since the latest commit. E.g. like changes in this commit.
If you don't have DeepSee resources, p.1 can be changed to Atelier or VSCode - both have the out-of-the-box functionality to export the source into files in UDL form.
HTH
Also worth checking Mirroring 101 by @Bob Binstock
Hi Thembelani!
For the new development with containers, the choice number one is InterSystems IRIS. You can try and build your solution with community edtion on AWS, Google or Azure.
If it is a solution in Healthcare I suggest starting even with InterSystems IRIS for Health.
As a development IDE with IRIS you have options of Atelier and now community driven VSCode for ObjectScript.
My personal preference is VSCode.
Thanks, Anastasia!
And we see it already working) @Dmitry Maslennikov redeemed the reward and is enjoying the promo of VSCode for ObjectScript this week.
Community members, did you notice?
@Dmitry Maslennikov, do you see the traffic?
Hi Nikita!
Don't know about the gas spending details, @Nikolay Solovyev will tell you more, but I'm curious on recurring billing - very interesting! Do you have this concept working already somewhere? Could you share a demo?
Like the clickable InterSystems Data Platforms tags in the repo:
@Dmitry Maslennikov , could you share, please, the code to be inserted into Reaadme.md to introduce it into the repo?
Yes, you cannot change the content of an accepted answer.
we did this intentionally: what is the reason to change the answer, which resolved the question?
New cool update came up with VSCode!
"objectscript.conn.active": true to enable itobjectscript.autoPreviewXML)..Name, ..SomeMethod()Well done, Dmitry!
This limit on Comunity Edition will be expanded with the next update.
Thank you, Vitaly! ObjectScript is full of opportunities! With a creative community, of course :)
But why "minus"? This is elegant and works.
You cannot, yes because of Accepted status.
Hi Sergey! Do not take Community Edition limits into consideration.
If you don't have limits what is the best strategy with packages/tools development in your opinion?
Yes, you are right.
I guess it is fair for the cases when the tool spawns jobs and does some work as daemons - like services, monitoring, alerting, etc. In this case data stays with XYZ database.
But I agree that we need a public registry of "safe" Class/Global prefixes and names.
We can take some easy and obvious approaches: Github or DNS.
E.g. with the Gihub approach the package name can start with a company.reponame.
Thoughts?
Thanks, Kyle!
Also, the option which worked:
ClassMethod valuesCollectionToDisplay(val, delim) As %String
{
quit ..AsJSON(val)
}
ClassMethod AsJSON(val) As %String
{
set res = []
set ptr = 0
while $LISTNEXT(val, ptr, el) {
do res.%Push(el)
}
quit res.%ToJSON()
}And the SQL call:
Select %EXTERNAL(values) values from dataNice writing, Nikita!
Just want to mention that there is a new community option to code ObjectScript you've probably never tried - VSCode plugin for ObjectScript by @Dmitry.Maslennikov.
A lot of developers can name VSCode as "favorite" IDE and the plugin can do really a lot for InterSystems IRIS developers today.
If tool XYZ is installed in namespace+database XYZ and consists of classes in the XYZ package that's %ALL-mapped from XYZ, default storage for persistent classes in that package will use globals ^XYZ.* which will get stored in the default data database of whichever namespace the tool is used in (e.g. USER). These globals mustn't clash with globals created in the same place by a tool from a different supplier, or by the end-user's own apps.
Right. And this is the reason why the tool with XYZ.Classes should be installed in XYZ namespace - in this way even if I map XYZ to %All all the data persistent data for XYZ.Classes will be stored in XYZ namespace, even if I use it from USER namespace, right?
Hi John! Thanks for the input. Why do you think we need a prefix for globals? The matter to have a dedicated namespace/database for the tool frees us from this requirement, right?
- There should be a central name registry, to avoid clashing on namespace/database names, package names etc between different package providers.
Agree, this is valuable. If we'll see thousands of modules. If we have a public package manager this will solve it I guess. But maybe "package name=repo name" rule could be a solver.
- What's the upper limit on namespaces? Databases?
I guess we have it in docs, but this number is large. Thousands I hope.
- Adding a namespace for each tool package will lengthen namespace lists in Studio, Portal etc. Maybe tools don't always need a namespace in front of their database. Ones that present a web app / REST interface probably do (at the moment) because of how the app config has to point to a namespace.
One of the options when tools could safely share one namespace when it has the same publisher. We often can imagine one company/developer who produces several tools which probably can be installed into one namespace/database.
Also available on Open Exchange!
Check a nice app COS Faker by @Henry.HamonPereira which is just for that. BTW, Henry! Let's publish it on Open Exchange?
INT code gives you the option to debug the related MAC, CLS or.. INT code. So it's for debugging purpose. And yes, it's stored in globals on disk and so needs disk space.