Defined in file: hzDatabase.h

hdbObject is a single data object container. Once a hdbObject instance has been initialized to a data class, it can hold a single object of that class. hdbObject is central to the data object repository program interface. In repository FETCH operations, hdbObject acts as a data object recepticle. In INSERT and MODIFY operations, hdbObject acts as the data object donor. The hdbObject GET value and SET value functions can only be applied to ATOMIC members of the class to which the hdbObject instance is initialized. Where a data class member introduces a subclass, the only way to access a subclass object and address its members, is via a separate hdbObject instance that is initialized to the subclass. Subclass objects are fetched by calling FetchObject() on the applicable host class member. Modified subclass objects are returned to the host class member by calling UpdateObject() on the same host class member. Entirely new subclass objects are calling AddObject() on the applicable host class member. Data objects members can be:- 1) A single BOOL or TBOOL 2) A single numeric value or a pointer to an array of numeric values 3) A single string value or a pointer to an array of string values 4) A single ENUM value OR a set of ENUM values encoded as a bitmap. 5) A single binary datum address OR a pointer into a hzChain that hold the actual binary datum. 6) A single subclass object address or a pointer to an array of subclass object addresses (see note). Within hdbObject members are assigned a slot in a uchar buffer (m_pCore), either to store a single value, or the address of the first value in a list of values. The size of the slot depends on the member data type and whether the member can have multiple values. Please note the following:- - BOOL and TBOOL members are always single value as they represent attributes the host class object either does, or does not have. Both are assigned a single core byte. - Numeric members are not usually configured to accept multiple values but it is permitted for 32 and 64-bit signed and unsigned numbers, and for doubles. In the single value case, numeric members are assigned core slots of their data size (8, 4, 2 or 1 bytes). In the multiple value case, a 4-byte aligned core slot is assigned to hold the address of the first value in the list. - STRING and string-like members are 32-bit entities whose values are stored within hdbObject by casting a 4-byte space, aligned to a 4-byte boundary, to the applicable C++ class (e.g. hzString). In all cases however, 4 bytes are assigned in the core, as both the value space (single value), and the address (multiple value), are 4-bytes in size. - ENUM members are given a 1 byte slot if only one value is allowed (max pop of ENUM data type 256), and 4 bytes if multiple values are allowed. As stated above, if the ENUM population is <= 32, the ENUM is stored as a 4-byte bitmap, otherwise the 4-byte value is the string address of an ecoded idset. - BINARY members are always single value. As binary datum cannot be indexed, BINARY members must be part of a class (or subclass), that has at least one member that can be indexed, in order for the binary datum to be found. BINARY members are assigned two core slots. An 8-byte aligned slot which is cast to a hzChain to hold the value, and a 4-byte aligned slot to hold the datum id, that the chain content either already does or will have in the binary datum repository. - Subclass members are always multiple as there would be no point to them if they were limited to a single subclass instance. Members can hold a lone subclass object or even be empty, but they cannot be limited to a single subclass object. Subclass members are assigned 4-byte aligned core slots, being the address of the first subclass object in the list. Slots are assigned in decending order of size, with 16 byte slots (type DIGEST) first, followed by 8-byte slots, then 4, then 2, then 1. This ensures the 8 and 4 byte slots are aligned to 8 and 4 byte boundaries. This is particularly critical for string and string-like members, as the slots are cast to hzString or other C++ string like class. Writing code to move data between data objects and program variables requires knowledge of the data class and its members, as is the case with all forms of structured data. hdbObject has various 'Get and Set' member functions which are overloaded to cover the whole set of HadronZoo data types. These expect a reference to a program variable and a member pointer. The compiler will not be able to check for type mismatches between program variables and member, so these functions return E_TYPE in this event. There is also a generic Get and Set which works with atoms, but these likewise cannot be type checked by the compiler. Get array and Set array functions are not currently provided but are being considered for applicable data types. Calling Set() on BINARY and TXTDOC members, sets the member to the actual binary datum supplied in the hzChain. However, when hdbObject is populated by a repository FETCH, only the binary datum id is loaded. This avoids expensive seek operations for binary datum that are quite often not needed by the task in hand. Calling Get() on the member explicitly, will pull the binary datum from the binary datum repository - providing there has been an initial FETCH on a data object repository. Data objects can be transmitted between services as JSON objects (the industry standard method). Within data object repositories, data objects are manifest as EDOs (encoded data objects). hdbObject has import/export methods for both formats. JSON and EDO formats are descrbed in the synopsis "Data Encoding". Note that hdbObject is often initialized to a data object repository, from which the data class can be inferred. This is necessary if the hdbObject is to be used to extract or to insert binary datum from/to BINARY or TXTDOC members, but not otherwise.

Constructors/Detructors

Public Methods:

Overloaded operators:

Member Variables: