Locations



Locations (sometimes referred to as logical locations) are a central feature of Deltanji's architecture. Whereas object versions constitute the units of your codebase, locations represent where that code is. In this way, they play three key roles:

  • To represent a stage along a development or workflow cycle.
  • To determine where a copy of the object versions' components should be physically stored.
  • To label sets of code, for example product releases.

Note: A fresh installation of Deltanji does not come configured with any locations. The system manager configures the environment to suit the organization. As such, any examples given in this documentation may not fit well with the system you are using. Your system manager may be able to help you if this is the case.

Master Location


Any one version of an object may be present at many locations, but only one of those locations can be declared to be the master location of the version.

Transfer routes can set which location is to become the master for the transferred version. Setting a particular location as the master location serves two purposes:

  • Identifying the "best" copy. Certain comparison operations choose this copy.
  • For yellow-folder locations (known as working locations), being the master location of the version allows Deltanji-aware editors to amend its component(s) there.

Representing a Development Stage


Locations are designed in this way so that you can enforce workflow procedures and ensure the integrity of your source base. For example, an environment with a very simple bug-fix cycle could have locations called 'Sandbox', 'Test' and 'CurrentRelease'. This would be the procedure that a developer would need to follow when fixing a bug:

  1. The master copies of the current software release are located at the 'CurrentRelease' location. The developer needs to check the relevant objects out from 'CurrentRelease' to 'Sandbox'. New versions of each object are created and they can be modified at this location.
  2. The developer checks them back in to the 'Test' location where they can be executed.
  3. Finally, they either pass the changes and transfer the object versions back to 'CurrentRelease', or fail them by checking them out again to 'Sandbox'.

Determining Physical Storage


Each location is mapped onto one or more physical locations. This means that an object version can have components which are stored in different storage formats and at different places, for example, an image which is a binary file in a directory, a web page which is a text file in a directory, and an InterSystems class in a namespace.

The following diagram gives an example of how a location might map onto physical storage spaces:

Each physical location may have more than one logical location mapped onto it. This can be used to divide the contents of a physical location into groups. For example, a test area may have a logical location for object versions undergoing testing and one for object versions which have been tested. Object versions can then be changed from Testing to Tested, without physically moving them.

To read more about how this works, see the article on physical storage.


See Also: Physical Storage, Locations Folder, Labels