Records are stored as stringified JSON objects. A Key is used to access these records on the server.
The internal record types supported is described in the Supported Record Types section of this page. The structure of each record is described in the Record Structure section of this page.
A key is used to retrieve the individual or batch or records. This key is described in the Key Structure section of this page.
Internally records need to be referenced with an address. This scheme is described in Addressing Records section of this page.
The updating of these records is covered in the sections Persisting Records and Dirty Data Detection and Update Conflict Resolution of this page.
A record is a JSON (external) or Javascript (internal) object. There are 2 types.
REC - individual records are grouped together under a single key. Processed by servREC API.
Internally this is a Javascript array of
Data Objects. Externally in the server this is a stringified JSON array of objects.
TBL - individual records. Processed by servTBL API.
Internally the single Data Object is represented as a Javascript object.
Externally in the server this Data Object is a stringified JSON object.
The REC can be stored as chunks when there are a large number or records. Typically this is around 64K blocks. This is used to limit the transmission size to the server at less the 100K since the Jetty server used by the Google App Engine imposes this limitation. The Triangular system manages this internally using the Addressing Records scheme to access the various chunks.
The Key is used to reference a record (TBL mode) or group or chunk of records (REC mode).
The key consists or 3 parts concatenated into a string of the form Part1/Part2/Part3 that becomes the unique key in the key/data pair.
cust - Part1, an alphanumeric customer or application id that separates the application records from all other application records on the server.
The User records used to secure access to the server use a special cust id and part 2 defines the apllication id.
type Part2, the record type extracted from the recType property of the Table (static version) definition.
The User records used to secure access to the server use a null for the specification of recType which internally triggers the controlled
access to these records.
key Part3 is the key extracted from the recName property of the Table (static version) definition (REC Mode).
In the case of chunked data this recName property will end with a '%' which will trigger the chunked mode support of Triangular. In this case the '%'
is replaced with a numerically ascending number representing each unique chunk.
For TBL Mode access Part3 is a unique string value used to locate the individual record. The value is often computed based on
user input data or time of day value (Deps.js example). The structure of this key if designed correctly can be used to find a subset of records using the
servGAE.issueFindFile function.
The record consists of a set of 'property' keys that point at data supported by JSON. Most common are string, numeric or boolean values.
It is possible to support sub-objects in that the JSON value can be another JSON object or array of objects. This is used in the "Deps.js" application in the donors column.
One or more fields can be marked with the many:false property in the Col (static version) definition which will cause Triangular
during the validation cycle to prevent duplicate values for this field. This creates a 'primary' key capability for a column value.
One or more fields can be marked with the reqd:false property in the Col (static version) definition which will mean the
field need not have some content. The default is reqd:true meaning the field must be populated with a data value.
More sophisticated validation can be invoked using the Table.validate exit.
Triangular by default inserts a tag property which assigns each record a unique integer number. This can be removed during the
Table.validate exit if not needed.
The server data block has a Datastore GekID which is an integer primary key to the block of data. For TBL Mode records this is used to remove a record.
The server also maintains an update timestamp for each block which is used in sections Dirty Data Detection and Update Conflict Resolution.
The Object Access Address or oaa is the internal means to reference records in the internal cache.
The value is either a numeric or a string. For TBL Mode the value will be 0. For non-chunked REC Mode it is the index (relative to 0) into the array of records in the cache.
For chunked data oaa is a string formatted as 'n.ix' where n is the chunk id and ix is the index into the chunk array.
For TBL Mode records the servTBL.insertRec function is used to add (key does not exist) or replace (key does exist).
For REC Mode records the servREC.saveRecords follows an servREC.insertRec function is used to add (oaa is null) or replace (oaa is not null).
The servTBL.insertRec bInter parameter allows intermediate states of TBL Mode records to be saved.
This cannot be reversed.
With the servREC.insertRec mode, the bInter parameter allows multiple inserts to take place before a final
servREC.saveRecords persists the data into localStorage and onto the server storage.
For TBL Mode the servGAE#dropObj is used to remove a record from storage.
For REC Mode the servCRUD.dropRecord is used to remove a record from storage.
When a Triangular application is marked in 'demo' mode (usually from a User Profile flag), the server storage save is skipped with the result that to the User it appears the update happens but they are never reflected to the server. Until localStorage on the User machine is cleared the updates will persist.
Dirty Data can occur when a User logs into the system from a different machine. The servGAE.login validates the timestamps of records against those in the localStorage cache. Any that differ cause the localStorage and memory cache to be updated with current values from the server.
The requirement for update conflict resolution occurs when 2 different Users attempt to update the same record with different values. At present the server detects this occurence, fails to make the conflicted update and reports back the failure to the User whose update failed. In future versions, in REC Mode the system will attempt to update the individual record within the array if it is not in conflict.
This is not an issue with the 'demo' mode system since the updates are never transferred back to the server.