James MacKeith · Apr 11, 2016

Explanation of the "%DEFAULTDB" database in 2016.1.0

During a fine breakfast at Global Summit 2016 I was asked about the %DEFAULTDB database that now appears when creating the %ALL namespace. Until the documentation on "Mapping a Package Across Multiple Namespaces"  is updated to include the use of subscript level mapping for all namespaces here is a brief explanation for this change in 2016.1: When creating a global subscript level mapping in the %ALL namespace the database that was used for the non-subscripted global could not be set to be the default database for each namespace. This behavior prevents using %ALL namespace to help manage subscript level mappings that are configured on all namespaces. Now in 2016.1.0 one enters %DEFAULTDB as the destination.  For example ^james("doc") mapped to COMMON database and ^james mapped to %DEFAULTDB   means data  in ^james("doc") will come from the COMMON database when in any namespace but all other ^james data will  be stored in the default global database for a namespace. Thanks to John Murray for the question.

0 437
Discussion (3)1
Log in or sign up to continue

Thanks to James for a prompt and detailed reply to my breakfast table question. Here I'm going to add this link to a previous posting of mine about %ALL, in part to highlight that %ALL mappings don't apply to 100% of the namespaces you have. The DOCBOOK and SAMPLES namespaces are apparently exempt. I can rationalize the DOCBOOK extension to myself, but the SAMPLES one puzzles me, especially given that the ENSDEMO namespace of an Ensemble or HealthShare instance is not exempt even though it's effectively another "samples" namespace.

On the other hand: if we would deal with SAMPLES and ENSDEMO similarly, and %ALL mapping  would work in SAMPLES the same way as for others, then leaving DOCBOOK alone would not make much sense :)

I'd prefer %ALL to work everywhere, without exceptions, that would significantly simiplify global mapping creation in some package manager you may be aware of.

I'd prefer not to use %ALL at all for a couple of reasons:

- if the mapping is created programmatically, it is not a problem to create it for each namespace,

- if it's created manually, one day you may forget about it and loose some important data or some other usefull things stored in non-default DB for years... of course, all this stuff should be documented and re-checked, but for me it is easier to do it once (for my nsp mappings) than twice (for my and for %ALL).