Announcement
· Jul 23

[Video] Organize Your Code with Namespaces

Hi Community,

What are the advantages of using multiple namespaces for your code? Learn some of the benefits in this discussion with @Derek Robinson, Senior Online Course Developer, and @Scott Clark, Implementation Specialist:

Using Multiple Namespaces

https://www.youtube.com/embed/J3mkQjDJNIc?utm_source=youtube&utm_medium=social&utm_campaign=J3mkQjDJNIc
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

In this video, you will hear some potential use cases for creating multiple namespaces.

Ready to try it yourself? See how to set up namespaces and databases in the Management Portal in InterSystems IRIS® data platform (video, 2m).

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

I appreciated this video as yet another resource for learning. Please do more!

The use case for the namespaces presented here seemed fringe to me.  If you need to simulate an FTP server, why not spin up a small container that does so.  Or are you talking about one HealthShare system to another HealthShare system?  

The common use for namespaces I've seen is separating dev, test, qa and production environments.  

I would personally like to understand better using namespaces to separate code versus data. Maybe this gets into the video's early point that one must understand the definitions. I guess I was taught to think of a namespace as a database, but when you see the following setting comes up in installation manifests it starts to get confusing because you have a code database and a data database in the same namespace and in this example I use the namespace as as the database name.  Maybe I'm just not understanding it at all!

<Namespace Name="${NAMESPACE}" Code="${NAMESPACE}" Data="${NAMESPACE}" Create="yes" Ensemble="1">

Thanks for sharing this video!

Hey Michael - thanks for your comment and for watching the video!

Namespaces in InterSystems IRIS or Health Connect are logical layers of abstraction that refer to one or more databases. They help organize and manage data and code logically. While databases are physical files storing data and code, namespaces act as references to one or more databases, offering flexibility in managing and accessing data and code.

Using namespaces to simulate environments, like test harnesses, provides an integrated approach within the IRIS environment. Here's a video that walks through an example use case that a Health Connect implementer might leverage -- using multiple namespaces to simulate the systems they are setting up for a customer.

Separating code and data within namespaces is typically a good idea for security & scalability. Your installation manifest example appears to keep code and data in the same database (named after the namespace), which can also be OK; but it would be a common practice to choose different databases for code and data within that namespace. I'm probably not the best person to speak to true best practices on that front... However, I think this video might also be helpful for you in understanding the distinction between namespaces and databases.

Thanks again for your engagement!

Although I have seen environments where namespaces are used to separate Dev/Test/Prod etc. I have found that having the Prod environment on the same environment as the Non-Prod Namespaces is a risk to the Prod environment should an active piece of development take down the underlying machine (one example was a developer* making a mistake when working with Streams and had created an infinite loop in writing a stream and the server very quickly gained a 10GB pdf that filled the disk to capacity and the environment stopped working).

A common use case for multiple namespace for me would be for instances where the activity within the namespace is significantly distinct from the others. For example, we have a namespace that is dedicated to DICOM activity. While we could have put this in a single "LIVE" themed namespace, the volume of activity we'd see for DICOM would have filled our servers disk if kept to the same retention period as other standard retention period. So we have a DICOM namespace that has a retention period of around 14 days compared to others that are between 30 and 120 days.

*It was me. I was that developer.