AllAccepted answers
Evgeny Shvarov · Feb 12, 2019

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?

Evgeny Shvarov · Feb 12, 2019

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.