JavaScript Object Notation (JSON)

JSON is not used by the HDB but because of its prevalance, JSON import/export methods have been added to the single data object container, hdbObject. HDB data objects are not fully compatible with JSON objects. All HDB data objects can be exported to a JSON object, but not all JSON objects can be imported into a HDB data object. As is widely documented, JSON is built on two structures as follows:-

The values in question, must be of the following:-

1) A string (sequence of 0 or more unicode characters) enclosed in double quotes 2) A number (decimal and standard form) 3) True/False 4) Null 5) An object (using {}) 6) An array (using [])

Hierarchy is supported by virtue of (5). Although JSON only has bool, number and string as atomic data types, JSON objects can be imported into a HDB data repository, providing:-

HadronZoo Data Object Notation (Whole Object Deltas)

HadronZoo Data Object Notation (HDON) is the formal name, of the format, used to represent whole data objects in the HadronZoo realm. Data object repositories store data objects as HDON objects in their data files. Microservices send and receive data objects as HDON objects. Note that HDON objects are often refered to as 'whole object deltas'. This is because they are identical in form to the whole object deltas issued by by data repositories on INSERT. Whole object deltas are part of HadronZoo Delta Notation (HDN), which is discussed in more detail later in this section. Regardless of the name, the format is as follows:-

@objX={ mY=value ... more member values }

Where X is the object id and Y is the member number. Where members have multiple values, there will be multiple instances of the same mY=. Subclass data objects are introduced via the applicable member as follows:-

@objX={ mYs={ ... subclass object members } }

HDON structure is where any similarity to JSON ends. JSON objects are self contained, HDON objects are not. HDON objects are shorthand and need a class description to qualify them. This must be obtained by the application before any HDON objects can be sent or received. Nor are HDON objects necesarily complete. If the object has BINARY or TXTDOC members, only the address of the binary datum appears in the HDON, not the binary datum itself. This reflects how data objects are stored in repositories.

EDO (Encoded Data Object)

The EDO format was developed as an experiment aimed at improving the space efficiency of RAM Primacy data object repositories. Hitherto data object repository caches, themselves an experiment, were arranged as a two dimensional matrix, i.e. a table. The data objects were of fixed size and were held in blocks of RAM in multiples of 64. This multiple was chosen so that litmus bits, needed for things like disambiguating zero, could be represented by 64-bit integers. Hierarchy was supported by having multiple caches, one for the native data class, another for each different subclass. Where applicable, members with multiple values were similarly supported by two additional caches, one for all 32-bit values and another for all 64-bit values. The arrangement offered excellent performance, and facilitated in-situ data operations. The standard practice of retrieving a whole object in order to access a single member, could be bypassed. The concern was wastage due to gaps, in the form of whole object deletions and blank members.

Eliminating this space wastage has an inevitable space cost. If gaps are squeezed out, the object and member ids cannot serve as offsets into the array, so the positions of objects within the block and of members within data objects, must be otherwise indicated. Any gapless variable length manifestation of a data object, i.e. the EDO, would need to explicitly state the object id, and state what members were present. In addition, any variable length entity, must either state its length or have a starting and/or terminating sequence.

An EDO begins with a serialized integer stating the length of the remainder or tail, of the EDO. The EDO tail begins with serialized integer to state the object id, which depending on the implementation, can be absolute or relative (to the starting object id of an EDO block). The object id is followed by a series of member litmus bits - one byte for every set of 8 litmus bits or part thereof. All members have one litmus bit to state if the member is populated. For BOOL members, this litmus bit is the value. TBOOL members have two litmus bits, the first states if a value is present and the second is the value. Other MEMBERS have an additional litmus bit if they are allowed multiple values, which in practice is rare except for members of a subclass data type. The final part of the EDO is a concatenation of member values, in order of ascending member id, that the litmus bits state are present - with arrays preceeded by a serialized integer to state the number of values present. The values themselves can be encoded as serialized integers, however currently, only signed and unsigned 64 and 32-bit integers use this option.

EDO structure depends on the approach taken to subclass objects. Where subclass objects are stored as an integral part of the host class object, subclass EDOs are nested within the host class EDO. Where subclass objects are held separately, only the object ids appear in the host class EDO. Note also that BINARY and TXTDOC datum are stored in a separate binary datum repository with only the datum id appearing in the EDO. The object and datum ids are of course, stored as serialized integers.

Strings and string-like values are represented within EDOs as string ids, with the actual string values held in string repositories (see article "String Repositories"). EDOs cannot be used outside the context of RAM Primacy because of this dependency.