0
1975

Written by

Stephen De Gabrielle
Integration Developer/Architect at London North West University Healthcare NHS Trust
Follow
Question Stephen De Gabrielle · Oct 3, 2017

Can a class refer to a global in a different namespace?

#Caché #Databases #Globals #Mapping

Some of our interfaces use globals for lookups, but we are currently looking at putting a groups of (document) interfaces in a separate production with a shared ‘Default Database for Routines’ to reduce code duplication.

We understand we could simply place these globals in the %SYS namespace so they can be accessed from all namespaces.

The manual seems to imply that using %SYS Namespace (CACHESYS database) to store globals is accepted practice, and establishes a strict naming convention to ensure globals are not overwritten.

Further down the same page (link below), 'percent globals' are introduced;

Any global whose name starts with a caret and a percent sign (^%). These globals are generally referred to as percent globals. Note that via global mappings or subscript level mappings, it is possible to change where percent globals are stored, but that has no effect on their visibility. Percent globals are always visible in all namespaces.

Should we be using percent globals or %SYS/CACHESYS globals to store the global we want accessible between namespaces? Can I explicitly address a global in another namespace/database?

--

System-Supplied Namespaces

Caché provides the following namespaces for your direct use:
  • %SYS — This namespace provides access to code that should not be available in all namespaces — code that manipulates security elements, the server configuration, and so on.
    For this namespace, the default routine database and default global database is CACHESYS. If you follow certain naming conventions, you can create your own code and globals in this namespace and store it in that database. See the next section.
  • DOCBOOK — The DocBook application uses this namespace.
  • SAMPLES — This namespace provides access to the SAMPLES database.
  • USER — This namespace provides access to the USER database.
Caché uses other namespaces for its own purposes; see “Configuring Namespaces” in the Caché System Administration Guide.
Custom Items in CACHESYS
You can create items in the CACHESYS database. When you install a Caché upgrade, this database is upgraded. During this upgrade, some items are deleted unless they follow the naming conventions for custom items.
To add code or data to this database so that your items are not overwritten, do one of the following:
  • Go to the %SYS namespace and create the item. For this namespace, the default routine database and default global database are both CACHESYS. Use the following naming conventions to prevent your items from being affected by the upgrade installation:
    • Classes: start the package with Z or z
    • Routines: start the name with Z, z, %Z, or %z
    • Globals: start the name with ^Z, ^z, ^%Z, or ^%z
  • In any namespace, create items with the following names:
    • Routines: start the name with %Z or %z
    • Globals: start the name with ^%Z or ^%z
    Because of the standard mappings in any namespace, these items are written to CACHESYS.
MAC code and include files are not affected by upgrade.

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GORIENT_ch_enviro#GORIENT_enviro_namespace_system

Discussion (4)2
Log in or sign up to continue

Comments

Steve Pisani · Oct 3, 2017

Hi Stephen,

I would avoid using the system database CACHESYS to hold your application globals.

You should create another database that  is specifically intended to hold the globals which would be common to all the productions you are running.

To enable the globals residing in this one, common database, to be visible from your various production namespaces - you would "map" these using Global Mapping rules defined against your production namespaces.

See the System Management Portal's Namespace configuration screens, and the Global Mappings feature, or look here: 

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_config_namespace_addmap_global  

Sincerely,

Steve

0
Amir Samary · Oct 11, 2017

Hi!

I wouldn't recommend putting globals or routines on your %SYS namespace for two reasons:

  • This will be shared with all namespaces. This may be what you want today, but may not be what you want in the future.
  • One nice thing to organize your code, globals and classes on different databases is that you can simplify your patching procedures. Instead of shipping classes, globals and routines from DEV to TEST or LIVE you can ship the necessary databases. So, if you have a database for all your routines/classes/compiled_pages, and you have a new release of your application, you can copy the entire CODE database from DEV to TEST or LIVE and "upgrade" that environment. Of course upgrading an environment may involve other things like rebuilding some indices, running some patching code, etc. But again, you can backup your databases, move the new databases to replace the old ones, run your custom code and rebuild your indices (if necessary) and test it. If something fails, you can always revert back to the previous set of databases. Well, you can't do that if you have custom code and globals on %SYS since copying the CACHESYS database from one system to another is taking more than what you would like to take from that system to the other.
  • With the new InterSystems Container Manager (ICM) that comes with InterSystems IRIS, there is this concept of "durable %SYS" where %SYS namespace is extracted from inside the container and put into an external volume. That is good because you can replace your container without loose all the system configurations you have stored on %SYS. But IRIS is not meant to be compatible with old practices such as taking care of your custom globals, routines and classes on %SYS. InterSystems may decide to change this behavior and make %SYS less custom code friendly.

So, you can perfectly create more databases to organize your libraries and globals and map them to your namespace without problems. One database for code tables, one database for some libraries you share between all your namespaces, one database for CODE another for DATA, etc. That is what namespaces are for: To rule them all.

Kind regards,

AS

0