HealthShare maps the Test package to HSLIB

If your Ensemble environment is actually a HealthShare one, here's a snippet of information that I wasn't able to find in the documentation.

When a namespace is HealthShare-enabled it gets some mappings added to it in order to fetch stuff from the HSLIB database. The most obvious mapping is a package mapping that gives your namespace all the HS.* classes.

Far less obvious is that your namespace will also be fetching/filing Test.* classes from the HSLIB database. So if you thought that, say, Test.MyExperiment was a good name for a little class you wrote in order to try something out, beware that it's not private to your namespace.

Why do I know this? When enumerating classes for the developer to select, our Deltanji source code management tool normally excludes any class that originates from databases other than the default routine (i.e. code) database of the namespace, because it's typically the responsibility of another namespace to source-control that class.

Does anyone have an explanation for this mapping of the Test package to the HSLIB database?

  • 0
  • 0
  • 245
  • 3
  • 1

Answers

My post got misclassified as a Question rather than an Article. I've added this dummy answer to remove it from the "unanswered" list.

Hi, John!

Why misclassified?

Does anyone have an explanation for this mapping of the Test package to the HSLIB database?

Is it not a question?

Comments

Hi John, can you please provide details on the version of HealthShare kit you are using? I just set up a new HealthShare instance and created a HS enabled namespace and do not see any Test.* package, global, or routine maps. I also checked back on a couple VMs with older instances and don't see any.

Matthew Spielman, Product Manager
HealthShare Information Exchange, Personal Community
InterSystems Corporation

This has been removed from more recent versions.

 

Saul