Physical Storage
Locations in VC/m represent stages or states in the workflow. When an object is transferred to a location, its components may also be copied or moved into a corresponding physical storage space. Where this is may vary depending on what type of component it is. For example, a text file, such as an HTML file, may be placed into a filesystem directory. However, a native Caché component such as a class may be placed into a namespace where it can be edited and executed. Alternatively, if the location is a library-view location, it may just be copied into the VC/m repository.
The system manager is responsible for determining the physical storage spaces that each location maps to. A developer needs to be aware of what these are so that they can access the components.
Mapping Structures
To see a location's mapping structure, navigate to the location in the folders panel. When you click on it, the main panel should display information about the location. There should be a section that looks something like this:
Note: Although the screenshot above pictures relative paths being used for physical addresses, the use of relative paths is discouraged. The reason they have been used above is because the VC/m environment that is pictured is the free 30-day evaluation kit. It uses relative paths so that the user is able to install the evaluation kit in a directory of their choice without compromising the physical storage mappings.
A mapping structure is a list of rules that VC/m refers to when transferring an object to a location. In the image above, you can see 4 rows. When processing the transfer, VC/m compares each of the objects' components with each mapping rule in order. In this case, it checks if the component is a text file with a .php extension. If so, it stores the component in text format at a physical address which is a directory: \pages\php. If the component does not meet the criteria, VC/m compares it to the next rule. This tests to see if the component is a text file. If so, it stores it in text format at the directory \pages. The third rules checks to see if it is a binary component. Finally, if it matches none of the preceding criteria, VC/m treats it as an M-specific component-type, and stores it in M format in the namespace VCM-DEV1.
For this particular location, this would be the outcome if several varied components were transferred to it:
| MAC.dbconvert | BIN.logo.png | T.formsubmit.php | T.readme.html | |
|---|---|---|---|---|
| T.*.php |
|
|
|
|
| T.* |
|
|
|
|
| BIN.* |
|
|
||
| * |
|
The following diagram demonstrates the mapping structure:
Working Location and Library-view Location Mapping
The mapping structure example given above would create a working location. This can be seen by the fact that components are stored at accessible addresses in an editable and executable format. A library view location, however, maps all of its objects' components to the library, from which they cannot be run.
The mapping structure for a library view location, therefore, looks like this:
| Component Mask | Storage Format | Physical Address |
|---|---|---|
| * | L | VCM-LIBRARY |
For more information about working and library-view locations, see the article on location types.
See Also: Locations, Components, Managing Physical Storage, Managing Locations, Location Types