Defining global, routine and package mappings that apply to (almost) all

Article

John Murray · Mar 11, 2016 1m read

In this posting I want to raise the profile of a feature that arrived in 2009.1 but is perhaps not very well known.

It is sometimes useful to make certain packages, globals or routines available to all of your namespaces. Of course you can add the necessary mappings whenever you create a new namespace, but here's a simpler way.

First you need a special namespace definition called %ALL. Create it in the same way you'd create any namespace. It doesn't matter which database you set as its default for code and data. I recommend picking CACHETEMP as a reminder that this namespace doesn't actually deal with its own databases.

Now you can add mappings to the %ALL namespace definition as usual. The effect is that these mappings apply to every namespace you have created and any you create in the future. It also applies to almost all of the standard namespaces. The exceptions are DOCBOOK and SAMPLES, according to the documentation here.

I've sometimes wondered why InterSystems doesn't pre-define the %ALL pseudo-namespace during installation. Doing so would raise the visibility of this feature. Any theories why not?

Herman Slagman · Mar 11, 2016

Even simpeler: it could be an option of the mapping settings. Then there is no need for this pseudo-namespace.

1 0

Dmitry Maslennikov · Mar 11, 2016

In our project we started to use it when InterSystems suddenly moved %cspSession global from CACHETEMP to CACHE. And after that, all our chnages in %session.Data started journaling. And to prevent it, we use %ALL to map this global to CACHETEMP.

Evgeny Shvarov · Mar 31, 2016

%All is quite useful namespace alias. Since it appeared hope nobody keeps creating %Package.Class classes and installs something in %CACHELIB when installs solutions.

0 0

John Murray · Mar 13, 2017

On the newer Cache versions you no longer need to pick a database when defining %ALL. Provided you tab off the "Name of the namespace" field after entering "%ALL", the form simplifies:

The above screenshot is from 2016.2.

John Murray · Mar 16, 2017

Perhaps worth linking to this post which explains the meaning of %DEFAULTDB in the above screenshot. The %DEFAULTDB setting arrived in 2016.1 and facilitates subscript level global mappings using %ALL.

Stephen Wilson · Mar 16, 2017

We don't have any plans to introduce new namespaces but I can see how this would be a useful feature for some people. We have 'training' and 'live' namespaces that have a one-to-one mapping with a database. It allows you to test software in a "logically partitioned" area of the production server. This setup has its quirks. When you copy a live routine into a training database you have to run a routine that essentially converts references to live namespaces and replaces them with training namespaces. Training namespaces always end in 'T'. If you forget to run this routine, you could accidentally modify the live data...

Defining global, routine and package mappings that apply to (almost) all namespaces