Managing Physical Storage
A physical storage space can be managed in Deltanji only when at least one location has been mapped to that space. (See the article on Managing Locations.)
To manage physical storage spaces, navigate in the folders panel to Setup -> Physical Addresses. If you have already set up some locations and mapped them onto some physical storage spaces, each physical address will be listed in the main panel:
By double-clicking on each physical address entry, you can view and modify the way in which Deltanji interacts with it.
When mapping a location onto a physical storage space, along with the physical address a storage format must also be specified. The combination of physical address and storage format constitutes a physical location. Managing physical storage space in Deltanji is done in terms of physical locations.
Physical Locations
Note: The term 'physical location' is generally avoided as much as possible when referring to the management of physical storage, so as to prevent its confusion with locations. However, the term still has a technical role to play in the structure of Deltanji.
A physical location is the unique combination of a physical address and a storage format. The following diagram shows two locations with the physical addresses to which they map their components. The physical locations are displayed in blue boxes:
In this diagram, the two locations - Location1 and Location2 - map to the following four physical locations.
| Physical Location Code | Storage Format | Physical Address |
|---|---|---|
| Location1$M | M | VCM-LOC1 |
| Location1$text | text | \usr\pages |
| Location2$bin | bin | \usr\pages |
| Location2$M | M | VCM-LOC2 |
Physical locations have the following properties:
- Single-version or Multi-version
- Controlled or Uncontrolled
- Dependency check
Single- and Multi-Version Physical Locations
Windows and UNIX operating system directories are only able to store a single version of an object at any one time. Libraries and sequential files, however, may be defined either as single-version or as multi-version, depending on the role they are to be used for.
Logical locations can also be defined as single-version or multi-version. A logical location which maps onto a multi-version physical location may be defined as single-version or multi-version. However, by definition, a logical location which maps onto a single-version physical location must only be single-version.
Note: Certain locations, e.g. Windows and UNIX operating system directories, also have a physical limitation in that they can only hold a single version of any component name at any one time. This means that when a component of the same name belongs to more than one object, only one of the component versions can exist in such a location.
Controlled and Uncontrolled Locations
A physical location has a type of controlled or uncontrolled. A controlled physical location is one which Deltanji expects to have full knowledge of.
An uncontrolled physical location is one whose contents Deltanji does not assume it has full knowledge of. Uncontrolled locations can be referenced within Deltanji in exactly the same way as controlled locations. The difference is that unregistered components are not protected from being overwritten in uncontrolled locations. For example, suppose a namespace contains the routine X.MAC that is not part of any object active at the location that maps MAC components to M-format storage in this namespace. In other words, MAC.X is an unregistered component. Transferring to this location an object with a component MAC.X will overwrite the existing X.MAC routine if the corresponding physical location is uncontrolled. By contrast, if the physical location is controlled the transfer will fail with the message "MAC.X exists at destination but is not registered to Deltanji".
Controlled is the default and this should normally be used.
Dependency check
When a location is used as a dependency on a transfer route, Deltanji may need to compare each component at this location with the same component at the from location. Component comparisons occur if the same version of the object being transferred is already active at the dependent location. The dependency check associated with the physical location for the component at the dependent location determines the mechanism which is used:
| Dependency check | Behaviour |
|---|---|
| Component Timestamp | Compares the component's native timestamps (e.g. class last-modified timestamp, file modification date/time) |
| Physical Compare | Compares components byte-by-byte |
| Deltanji Internal Timestamp | Compares Deltanji's own internal date/time stamps |
| Best Available | If the component driver supports getting and setting of native timestamps a 'Component Timestamp' check is performed. Otherwise a 'Physical Compare' check is performed. See note below. |
The default for new physical locations is 'Best Available'.
The 'Physical Compare' check will be the most accurate but it will also be slower than the others, particularly where Deltanji is managing code on remote nodes.
The 'Component Timestamp' check will only work for components which have a native date/time stamp. For example, operating systems typically record the date and time when a file is modified, but a Caché/M implementation does not record the date and time when a global is modified.
The 'Deltanji Internal Timestamp' check is unsuitable if the editor being used is not interfaced to Deltanji. Without an editor interface, the Deltanji internal timestamp will not be updated when the component is changed by the editor.
Note #1: CSP and CSR components transferred to 'M' storage format, and component types transferred to 'bin' or 'text' storage formats (e.g. BIN or T type components) will only have their native timestamp propagated by the transfer if Deltanji is able to use a Perl interpreter. See here for more information. Failure to set this up correctly can lead to repeated automatic transfers if 'Best Available' or 'Component Timestamp' is used.
Note #2: For the 'Deltanji Internal Timestamp' check, the components do not physically have to exist at the location.
See Also: Physical Storage, Managing Locations