Explanation of the "%DEFAULTDB" database in 2016.1.0

Question

Question

James MacKeith · Apr 11, 2016

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.

Discussion (3)1

Log in or sign up to continue

John Murray · Apr 12, 2016

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.

0 0

Alexey Maslov · Apr 15, 2016

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

0 0

score 0 · Answer 1 · 2016-04-12T07:30:31-04:00

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.