Storage Location Concepts

Storage Locations provide FOX with a standard mechanism for accessing/updating units of data. They are a definition of how and where data is stored and accessed. They differ from fm:query definitions as Fox decides where, when, and how to use the SQL/DML defined within the Storage Location.

SYNTAX

The following code shows what might be included within a storage location:

<fm:storage-location name="name">
  <fm:cache-key string="module name :bind">
    <fm:using>bind xpath</fm:using>
  </fm:cache-key>
  <fm:new-document>
    <fm:root-element>root</fm:root-element>
  </fm:new-document>
  <fm:database>
    <fm:query>
     <fm:sql>
sql statement with :bind
     </fm:sql>
     <fm:using>bind xpath</fm:using>
    </fm:query>
    <fm:insert>
      <fm:sql>
dml statement with :bind
      </fm:sql>
     <fm:using>bind xpath</fm:using>
    </fm:insert>
    <fm:update>
      <fm:sql>
dml statement with :bind
      </fm:sql>
    <fm:using>bind xpath</fm:using>
    </fm:update>
  </fm:database>
</fm:storage-location>

CONCEPTS

A global caching mechanism is used across the FOX System. Data is loaded into the memory cache bucket, which is identified using a cache key (I.E. the name of the bucket). All operations are performed on the data held in the memory cache as this provides best performance. Because the caching mechanism is global across FOX, two different user sessions, running different modules can access a common unit of data - simply by addressing the same bucket (I.E. using the same cache key). This means both users can benefit from seeing the common data consistently and quickly, whilst system memory is optimised as only one version of the data is held.

You can have multiple storage location definitions within a module, but each one should have a unique cache key and name.

Across modules, the cache key must be unique for discrete data. Common data can however be reused by engineering a repeatable cache key. 

• Storage Location is a definition of how and where something is stored
• Defines all database SQL and DML to access a single row of information
• Complex internal caching aids performance and data sharing
• When a module is loaded, a cache key is generated. This is used as a name of a memory location to store retrieved information for that module
• It is important to get this correct, as two modules with the same storage location cache key will use the same memory location (bucket). If different data structures are involved, this is very bad as the two data structures may be corrupted
• A cache key should include some relevant text as well as either a unique bind variable or a bind variable that has been passed into the module
• The cache key for most modules will be the module name, and some bind variable
• Storage locations are used for accessing:
• Short term computed lists of values (map-sets, covered next)
• Static lists of values (map-sets)
• Module Data DOM – XML stored in database
• Files stored on the database (e.g. Uploaded Word files)

EXAMPLES

An example of a storage location for a module called MOD012X that had no variables passed into it and would use a unique bind variable is:

 <fm:storage-location name="main">
  <fm:cache-key string="MOD012X:1">
    <fm:using using-type="UNIQUE"/>
  </fm:cache-key>
  <fm:new-document>
    <fm:root-element>ROOT</fm:root-element>
  </fm:new-document>
</fm:storage-location>

For the same module, but with a variable called ID passed into the module, you would use the following code to declare the storage location:

<fm:storage-location name="main">
  <fm:cache-key string="MOD012X:1">
    <fm:using>:{params}/ID</fm:using>
  </fm:cache-key>
  <fm:new-document>
    <fm:root-element>ROOT</fm:root-element>
  </fm:new-document>
</fm:storage-location>