Meta object model for relational data storage

This article describes the idea of use a meta model to store RPClasses and RPObjects. It is not planned to actually do this anytime soon.

Object Model of Marauroa

Marauroa supports definition of classes and attributes at runtime. The type information is stored in instances of RPClass. Instantiated Objects are RPObjects which must obey the rules defined in their associated RPClass. Associations are defined in RPClass as well and the links on the instance layer are represented by RPSlot instances.

The basic Meta Model

This chapter will describe a generic meta model for object orientated systems.

Model Layer

Let's start with thinking about the model layer. It consists of classes with their attributes and associations. In addition to that the classes form a hierarchy of specializations.

In Marauroa "associations" are named "slots". They don't have a target type.

Instance Layer

Based on the model layer instances can be created:

It consists of objects (4711 of type Player), values (43 for atk) and links (items in the bank_slot). Of cause there are some consistency conditions required. For example value.object.class <= value.attribute.class.

Converting the Meta Model into a database structure

TODO: ...

CREATE TABLE class (id SERIAL, name VARCHAR);

CREATE TABLE inheritance (id SERIAL, sub_class_id INTEGER, super_class_id INTEGER);

CREATE TABKE attribute_type (id SERIAL, name VARCHAR, class_id INTEGER, type CHAR(1));

CREATE TABKE association_type (id SERIAL, name VARCHAR, class_id INTEGER, class_id INTEGER);

CREATE TABLE object (id SERIAL, class_id INTEGER);

CREATE TABLE value_char (id SERIAL, attribute_type_id INTEGER, object_id INTEGER, value VARCHAR);

CREATE TABLE value_int (id SERIAL, attribute_type_id INTEGER, object_id INTEGER, value INTEGER);

CREATE TABLE value_blob (id SERIAL, attribute_type_id INTEGER, object_id INTEGER, value BLOB);

CREATE TABLE link (id SERIAL, association_type_id INTEGER, object_id INTEGER, target_object_id INTEGER);

There is a type layer at the top, consisting of classes (e.g. Player), attributes (e. g. ATK) and associations (e. g. bank_slot). The Inheritance is the reference to the super object (Player, RPEntity)

The second block is the instance layer. It consists of objects (4711 of type Player), values (43 for atk) and links (items in the bank_slot). Of cause there are some consistency conditions required. For example value.object.class <= value.attribute.class.

This basic model can than be easily extended. For example in our case we want a sort order in links table. And because some databases are very slow at deleting rows, or just in case we may want a revision safe system there is an easy way to achieve that: Add a new table activity which basically has a timestamp. All the table on the instance layer get two additional columns: created_activity_id and deleted_activity_id. This is a lit bit redundant but required for performance reasons. Together with a second trick, the whole system is much faster as one would guess: This trick is to have two special activities: "beginning of time" (lowest possible date) and "end of time" (highest possible date). This allows to greatly simplify the queries, because deleted_activity now always has a valid value. Life objects are simply deleted at the end of time.