Form Storage -- Multi-Flat Table

The Multi-Flat form storage mechanism is similar to the flat form storage mechanism excepting that the data used to populate the form can come from multiple databases and tables. The Multi-Flat storage mechanism is intended for data aggregation purposes. It does so by considering each database/table to contain the data from one locality.

For example, you may have several regions each running an instance of iHRIS Manage. You may wish to aggregate data maintained within each of the regions (e.g. people and positions, but not jobs or geographic locations) into a central instance of iHRIS Manage so that you can run reports on the entire country. When setting up the central instance of iHRIS Manage, you could choose to use the Multi-Flat storage mechanism for people and positions. Then on the central server, you could create a database for each region, (Region1, Region2, etc.) which would simply contain the cached tables for people and position for each of the respective regions.

For the data such as jobs or geographic locations, which should be centrally maintained, we encourage you to use the magic data form storage mechanisms.

Specifying Multi-Flat Storage

To specify that the form $form has a Multi-Flat table storage mechanism set by setting

modules/forms/forms/$form/storage

to have value 'multi_flat.

Form Options

The options specifying a Multi-Flat table storage for $form are stored at:

/modules/forms/forms/$form/storage_options/multi_flat

It has the following structure (which is identical to those for flat storage):

• table: Required scalar node. The table to use, e.g. hippo_person. You are responsible for back-tics if required. The same table name will be used across the multiple databases, with each database representing an individual locality)
• id: Required parent node. The data defining how to associate an id per row of this table.
  • col: Optional scalar node. Specifies a column of the table to be used as the id. You are responsible for back-tics.
  • function: Optional scalar node. Specifies a SQL function whose result will the id for the form. 'col' takes precedence.
• writable: Optional scalar node. Defines the write access to the table. If not present or its value cast to false, then the table is not consider to be writable. If its value casts to true, then it is considered writable and the save() method will actually do something.
• fields: Optional parent node. Specifies how the data of the your form is associate to a row of your table. Each child of this node is the name of a field $field of your form.
  • $field: Parent node with the following child nodes.
    • col: Optional scalar node. Specifies a column of the table to be used as the id. You are responsible for back-tics.
    • function: Optional scalar node. Optional scalar node. Specifies a SQL function whose result will as the value for the field. 'col' takes precedence.
• parent: Optional parent node. If not present, this form has no parent and getParent() returns 0. It has the following child nodes:
  • enabled: Optional scalar node. If set and evaluates to true, it means we should return a non-trivial parent id.
  • col: Optional scalar node. Specifies a "column" of the table to be used as the id for the parent. You are responsible for back-tics.
  • function: Optional scalar node. Optional scalar node. Optional scalar node. Specifies a SQL function whose result will as the value for the parent form's id. 'col' takes precedence.

In addition, we will need to mark this form as being localized. You do so by setting

 modules/forms/forms/$form/localized 

to be 1.

Global Options

There are global options for specifying a the mapping between localities and databases

/modules/forms/storage_options/multi_flat

This has the structure:

• databases: Required parent node. It's child nodes are the names of each of the localities (e.g. Regions) you will be reading from.
  • $locality: Scalar node. It's value is the database where the tables for the $locality are stored.

For example you might have the following:

• databases
  • north => NorthernRegionDatabase
  • south => SouthernRegionDatabase
  • east => EasternRegionDatabase
  • west => WesternRegionDatabase