Question
· Nov 25

Regarding best practices for integration between different datasets and namespaces.

#InterSystems Business Solutions and Architectures #Key Question #Caché #InterSystems IRIS

In some cases, it's necessary to manipulate data from one namespace to another. For example, a routine in the "N1" namespace needs data from the "N2" namespace. In legacy systems (using only globals), it's common to make the global universal, but what about persistent classes? Is this type of globalization also possible?

In the same context, how could I make a persistent class global for all namespaces? The only way I know is by putting it in %SYS. For example, to build a class from the "N1" namespace in the "N2" namespace, I need to use the pipe or the ZN function, but this somewhat reduces the productivity of the IDE (VS Code, Studio...), because the class doesn't exist in the namespace I'm working in, and this affects the autocomplete of methods, attributes, etc.

What would be the best practices for these use cases? Can I build this type of class in %SYS?

Product version: Caché 2018.1
Discussion (7)3
Log in or sign up to continue
DC AI Bot · Nov 25

Manipulating data across namespaces and ensuring persistent class globalization has comprehensive conditions:

  1. Changing Namespaces:

    • You can change the namespace within application code using the ZNSPACE command or directly setting the $NAMESPACE special variable (recommended approach within routines). Use $NAMESPACE to establish a context that automatically reverts when the routine concludes [1][2][3].

  2. Persistent Class Sharing Across Namespaces:

    • Persistent classes and global variables cannot directly be shared universally across namespaces except if created in the %SYS namespace. Items in %SYS, including classes starting with % or %Z, are accessible universally [4].
    • As a best practice, avoid performing globalization by storing persistent classes globally unless necessary for security and organization reasons. Instead, properly configure namespaces with mappings for persistent classes [4].

  3. Effect on IDEs and Usability:

    • Using classes from another namespace affects IDE productivity like autocompletion. When using the IDE, you may need mapping settings that allow declaration and interaction with the class structure in multiple namespaces while eliminating the need for namespace switching (like $NAMESPACE or ZNSPACE) mid-code [1][2].

  4. Globals in All Namespaces:

    • To make globals accessible across namespaces, you can configure process-private globals or use extended references like ^$|namespace|GLOBAL(obj) [5].

  5. Efficiency Recommendation:

    • By avoiding frequent namespace changes (ZN or $NAMESPACE) and leveraging unbound persistent classes or global usage standards within your configuration, you minimize IDE inefficiencies and ensure consistent integration [5][4].

For further detailed implementation strategies, you might need specific examples based on coding contexts [3][4].

Sources:

0 0
Vitaliy Serdtsev · Nov 27

As you can see, the author asked two questions:

  1. In some cases, it's necessary to manipulate data from one namespace to another. For example, a routine in the "N1" namespace needs data from the "N2" namespace.
  2. In the same context, how could I make a persistent class global for all namespaces? The only way I know is by putting it in %SYS.

What would be the best practices for these use cases?

I answered the second question, and the other participants answered the first.

0 0
Stephen Canzano · Nov 25

If we look to what InterSystems provides as an application like Ensemble(Interoperability) or HealthShare we will find the class defintions exist in the ENSLIB or HSLIB namespace.  Then via Package mapping you will find that Interoperability enabled namespaces or HS enabled namespaces map the package definitions.  For example in the namespace HSEDGE1 we see

which says the classes from these packages are visible to the HSEDGE1 namespace.  

The data for the extent of these classes by default would live in the associated db for the namespace HSEDGE1.

In most cases the data for the extent is not mapped so as to live in a single univeral database but generally speaking it could be, although in the case iof the Ensemble/Interoperability and HealthShare data you shoud not do this.

1 0