Mapped values

Maps, structs, arrays and heap allocated objects provide the basis for having many independently updatable variables in a database.

Consider the following data type expressed in the Xc++ language (which is an extension to C++ to support reflected data types, persistence, replication and synchronisation).

$model+ Point
{
    int32 x;
    int32 y;
};

The Point type is a value type which is essentially a struct with two member variables named x and y which are independently updatable. There is no constraint defined across them.

Consider the following definition of a type named X. This is a reference type meaning that object instances are intended to be heap allocated, and they are referenced from other objects by pointers. This allows object graphs to persist in the database.

$struct+ X isa IPersistable :
    model
    {
        xvector<int64> s;
        xmap<string8, Point[5][4]> m;
        float64 f[6];
    }
{
};

This reference type contains a model. The members of the model are independently updatable.

Let the following code be used to generate an operation:

X* p = $new X;

// Generate operation
(*p).m["a"][3][2].x = 3;

The operation is parameterised by a list of values/identifiers which identify the variable which is the target of the update.

[ 0x1ef42340, m, "a", 3, 2, x ]

Encapsulation and class invariants

An important concept of OO languages is the idea of encapsulation [] in order to enforce a class invariant []. A class invariant represents a constraint on the class member variables. It's quite common for the value of one member to affect the possible values of another member. That means they are not independently updatable.

In this sense the data structures in a CEDA database which are the target of updates are like structs rather than object instances of OO classes.