The design goal of Clear ODB was to create an distributed computing platform that will help with development in object oriented languages. The most important objective was to make the interface to the system as easy as possible to use for an application developer. This would mean that objects as you use them in your application would be the means of inserting and retrieving data.
Inserting and retrieving data is always done with objects defined in the language of choice. When you select objects, you always select complete objects, rather than as in a relation database where you select the fields you want to retrieve. Also, when you insert or update objects, you always insert or update the whole object, not just single fields. (This may change in future releases.)
Another important aspect of selecting objects is that objects' relationships in an object oriented language are deterministic. One object may refer or point to one or more other unique objects; the reference or pointer used for this relationship is not subject to the values of an object's member fields.
If the closest comparison to an object in a relation database is a record in a table, it is easy to see one of the most important differences between a relational model and an object model. In a relational database, relationships between records are expressed as conditions on the record's columns or fields, while in the object oriented model the member fields have no impact on which object a reference is pointing to.
When you design your object model, you will most likely end up with a number of classes with pointers/references to other classes. When using Clear ODB, and inserting an object pointing to other objects, the Clear ODB will make a deep copy, following through all pointers in all objects that are reachable by the object inserted.
The same applies for selecting objects. The database will return all objects pointed to by the selected objects (and recursively return all objects that were inserted in the first place).
To prevent loading the entire object model through these recursive lookups, a special 'light' reference type is available (in C++, osl::ref<>). It overloads the pointer operator, and thus acts like a pointer. However, the recursive lookups will stop with the reference. Only once the application tries to access the pointed-to object will a request for loading it be sent to the server.
Objects are retrieved from the server using either:
The possibly strongest points for an object oriented data model is inheritance for data modelling and polymorphism for generic programming. These two features enables code reuse and clean cut interfaces that are difficult or requires substantial amount of effort to implement using other data modelling methodologies.
The ability to create hierarchies of data types makes it easy to model real life entities. It also makes it very easy to extend the data model without touching existing data types, thus ensuring that existing functionality can still work without modification, yet at the same time being able to reuse what is already in place.
Clear ODB supports most of the inheritance structures that C++, Java and C# can implement. This enables you to take advantage of an object oriented design without having to develop the functionality required for storing and retrieving objects, as would be required if non-object oriented storage solutions were used.
Polymorphism in Clear ODB is the ability to select on fields in a base type and retrieve objects of all sub classes. Select queries can be applied to any level of the class hierarchy. You can also select on a base class field, but only return objects of one sub class.