Introduction to Namespaces and Databases
Introduction to Namespaces and Databases
In InterSystems IRIS, any code runs in a namespace, which is a logical entity. A namespace provides access to data and to code, which is stored (typically) in multiple databases. A database is a file — an IRIS.DAT file. InterSystems IRIS provides a set of namespaces and databases for your use, and you can define additional ones.
In a namespace, the following options are available:
A namespace has a default database in which it stores code; this is the routines database for this namespace.
When you write code in a namespace, the code is stored in its routines database unless other considerations apply. Similarly, when you invoke code, InterSystems IRIS looks for it in this database unless other considerations apply.
A namespace also has a default database to contain data for persistent classes and any globals you create; this is the globals database for this namespace.
So, for example, when you access data (in any manner), InterSystems IRIS retrieves it from this database unless other considerations apply.
The globals database can be the same as the routines database, but it is often desirable to separate them for maintainability.
A namespace has a default database for temporary storage.
A namespace can include mappings that provide access to additional data and code that is stored in other databases. Specifically, you can define mappings that refer to routines, class packages, entire globals, and specific global nodes in non-default databases. (These kinds of mappings are called, respectively, routine mappings, package mappings, global mappings, and subscript-level mappings. )
When you provide access to a database via a mapping, you provide access to only a part of that database. The namespace cannot access the non-mapped parts of that database, not even in a read-only manner.
Also, it is important to understand that when you define a mapping, that affects only the configuration of the namespace. It does not change the current location of any code or data. Thus when you define a mapping, it is also necessary to move the code or data (if any exists) from its current location to the one expected by the namespace.
Defining mappings is a database administration task and requires no change to class/table definitions or application logic.
Any namespace you create has access to most of the InterSystems IRIS code library. This code is available because InterSystems IRIS automatically establishes specific mappings for any namespace you create.
This book has mentioned some of these classes; to find tools for a particular purpose, see the InterSystems Programming Tools Index.
When you define a namespace, you can cause it to be interoperability-enabled. This means that you can define a production in this namespace. A production is a program that uses InterSystems IRIS Interoperability features and integrates multiple separate software systems; to read about this, see Introducing Interoperability Productions.
Mappings provide a convenient and powerful way to share data and code. Any given database can be used by multiple namespaces. For example, there are several system databases that all customer namespaces can access, as discussed later in this chapter.
You can change the configuration of a namespace after defining it, and InterSystems IRIS provides tools for moving code and data from one database to another. Thus you can reorganize your code and data during development, if you discover the need to do so. This makes it possible to reconfigure InterSystems IRIS applications (such as for scaling) with little effort.
Locks, Globals, and Namespaces
Because a global can be accessed from multiple namespaces, InterSystems IRIS provides automatic cross-namespace support for its locking mechanism. A lock on a given global applies automatically to all namespaces that use the database that stores the global.
For an introduction to locking, see “Locking and Concurrency Control,” earlier in this book.