· Mar 11, 2016 1m read

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

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?

Discussion (6)1
Log in or sign up to continue

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