The Object Definition Language

The EYEDB Object Definition Language (ODL) is a language based on the ODMG ODL to define the specifications of object types.
ODL is not intended to be a full programming language, it is a definition language for objet specifications.

Like ODMG ODL, EYEDB ODL defines classes (inheritance and attributes), relationships and method signatures. EYEDB ODL extends the ODMG ODL to allow the definition of attribute constraints (notnull, unique, collection cardinality), index specifications and trigger declarations. Unlike ODMG ODL, any instance of a class can be used either as a literal or as an object. EYEDB ODL also allows the user to specify whether a method is backend (i.e. server side) or frontend (i.e. client side), and whether it is a class or instance method.

Here is a simple example of an EYEDB ODL construct:

enum CivilState {
  Lady = 0x10,
  Sir  = 0x20,
  Miss = 0x40
};

class Address {
  attribute string street;
  attribute string<32> town;
};

class Person {
  attribute string name;
  attribute int age;
  attribute Address addr;
  attribute CivilState cstate;
  attribute Person * spouse inverse Person::spouse;
  attribute set<Car *> * cars inverse Car::owner;
  attribute Person *children[];

  instmethod void change_address(in string street,
                                 in string town,
                                 out string oldstreet,
                                 out string oldtown);

  classmethod int getPersonCount();
  index on name;
};

class Car {
  attribute string brand;
  attribute int num;
  attribute Person *owner inverse Person::cars;
};

class Employee extends Person {
  attribute long salary;
  Person *boss;
};

This example illustrates all the concepts that we described previously.
The class Person is composed of a number of attributes each of one having an interesting particularity.
The name attribute is a variable size character array, i.e. a string.
This attribute is literal, which means that it has no identifier within a database. The hint index means that this attribute should be indexed to provide efficient query according to the attribute value.

The age attribute is a simple literal 32-bit integer.

The addr attribute is a literal user type attribute. As this attribute is literal, the type attribute, Address, must have been defined before, which is the case.

The next attribute spouse has two interesting particularities:

1. a * character follows the user type Person, meaning that this attribute is not a literal but an object (i.e. with an identifier). The * character means a reference to an object.
2. the hint (invers Person::spouse following spouse means that this attribute is a relationship.
   As the attribute spouse is not a collection and the target attribute spouse is not a collection, this is a one-to-one relationship.

The cars attribute has also several interesting particularities:

1. as a * character follows the user type, this is an object.
2. this attribute is a set whose elements are object of type Car. Note that the user type Car is defined after.
3. the hint (inverse Car::owner following cars means that this attribute is a relationship whose target is the owner attribute within the class Car.
   As the source attribute cars is a collection and the target attribute owner is not a collection, the relationship is a many-to-one relationship.

As indicated by the keyword instmethod, the method change_address is an instance method. Note that this keyword is optionnal as this is the default.
The method getPersonCount is a class method as indicated by the classmethod keyword.

The class Employee inherits from the class Person as indicated by the keyword extends. It introduces two attributes salary, a literal integer attribute and boss, an object attribute which reference an instance of the class Person. Note that as there is no relationship indication (i.e. inverse keyword), the boss attribute is an object-valued attribute (i.e. a unidirectionnal relationship): in this case, EYEDB does not guarantee the referential integrity.