New post
AllAccepted answers
John Murray · Apr 9, 2019

I notice that your mappings get code from ENSLIB

My use-case is a bit different.

Can you create a new database and namespace pair called XYZ and then define a %ALL mapping so that the globals ^XYZ and the routines XYZ* and the package XYZ get fetched from your XYZ namespace from all other namespaces, e.g. USER ?

I'd expect mappings to ENSLIB to work, otherwise the "Ensemble" features of IRIS would be broken in Community Edition.

It seems to me that those are allowed but mappings we define to our own databases get ignored.

John Murray · Apr 9, 2019

There's a section about Community Edition limitations in the document at https://irisdocs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page...

Here's a screenshot of what it currently says:

A big disappointment for me is the exclusion of namespace mapping. Those of us who create tools for the InterSystems world commonly use namespace mapping to make our tools available in the users' namespaces. See Evgeny's article here

John Murray · Apr 3, 2019

Expanding on what Evgeny wrote, the new Serenji extension from us at George James Software gives you an experience that's most similar to what you're used to with InterSystems Studio. It connects you directly to the namespaces of your servers, even if they're running versions that are too old to support the Atelier REST APIs which other VSCode extensions depend on.

Plus, Serenji offers debugging.

John Murray · Mar 27, 2019

To clarify Robert's answer, on InterSystems IRIS the database is called IRISLIB, and on Caché, Ensemble etc it is called CACHELIB.

But rather than having to reload your own non-%Z/%z routines after every upgrade you could create a dedicated database for those routines and then use %ALL-type mapping to make the routines available in all of your namespaces.

More info:

John Murray · Feb 21, 2019

Take a look at methods in the %SYSTEM.Encryption class.

Like many of the classes in the %SYSTEM package, you can easily access its methods via $SYSTEM, e.g.

USER>d $system.Encryption.Help()
'Do $system.Encryption.Help(method)' will display a full description of an individual method.
 
Methods of the class: %SYSTEM.Encryption
 
AESCBCDecrypt(ciphertext,key,IV)
     This method performs AES decryption in Cipher Block Chained (CBC) mode.

...
John Murray · Feb 12, 2019

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?

This is only true if you explicitly add a global mapping of ^XYZ.* to the XYZ database (NB, mappings point to databases, not to namespaces). If you only mapped the XYZ package to XYZ, when an instance of persistent class of that package is saved from within the USER namespaces its data will get stored in the USER database.

John Murray · Feb 12, 2019

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?

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.

If tool XYZ opts to consolidate user's data into the XYZ database, the natural way of doing this is with package mapping, in which case it's still necessary to avoid name collisions. There are ways the XYZ tool could use extended global references to route data into its private database, but this adds complexity.

John Murray · Feb 12, 2019

Some initial thoughts:

-  There should be a central name registry, to avoid clashing on namespace/database names, package names etc between different package providers.

- Consider assigning a top-level reserved package name (also prefix for globals and routines), and a namespace/database prefix, to avoid clashes with names that end-users of the tools might pick.

- What's the upper limit on namespaces? Databases? Any relevant constraints for Community Edition of IRIS?

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

- Tools should be able to register stuff that needs to be run during environment startup and shutdown. The current need to create/edit %ZSTART / %ZSTOP routines is clunky.