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.
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.
What platform are you running Cache on? And what Cache version? Can't you access the Windows fileshares directly from ObjectScript without needing to call out through the Java gateway?
The IRIS-based products don't ship a SAMPLES database. Instead there's a documented procedure for setting up your own, then fetching the samples you want.
In that case I'd like to lobby for devchange JGM785 to get into Ensemble 2018.1.2. This devchange addresses a longstanding weakness in Portal, namely that its schema editor didn't respect server-side source control.
I shall be there from the Tuesday lunchtime until Wednesday night and will be happy to demonstrate it wherever people want to gather round my laptop. There isn't a Partner Pavilion at the event.
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.
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.
What platform are you running Cache on? And what Cache version? Can't you access the Windows fileshares directly from ObjectScript without needing to call out through the Java gateway?
What $ZVERSION are you running?
The IRIS-based products don't ship a SAMPLES database. Instead there's a documented procedure for setting up your own, then fetching the samples you want.
In that case I'd like to lobby for devchange JGM785 to get into Ensemble 2018.1.2. This devchange addresses a longstanding weakness in Portal, namely that its schema editor didn't respect server-side source control.
Is there an ETA for 2019.1 preview versions of Caché and Ensemble, for those who haven't yet migrated to InterSystems IRIS?
I shall be there from the Tuesday lunchtime until Wednesday night and will be happy to demonstrate it wherever people want to gather round my laptop. There isn't a Partner Pavilion at the event.
I shall also be there with the VSCode extension from George James Software.
It's now confirmed that I shall be attending the InterSystems Benelux Symposium.