OOFILE vs ODMG-93

ODMG-93 is a standard established by a working group composed of 5 representatives of many (most?) of the OODBMS vendors. The standard is documented in "The Object Database Standard: ODMG-93" ed. R G G Cattell, ISBN 1-55860-302-6. Updates can be found online at http://www.odmg.org/

Remember that one of the goals of OOFILE is to allow mapping onto existing record-oriented and RDBMS databases, as well as acting like a traditional ODBMS. This has required some additional operators, and I've made a substantial effort to simplify the syntax used by the programmer, so ex-4GL users will feel at home.

ODMG-93 includes definitions of terms, manipulation and query languages and both C++ and SmallTalk bindings. The following explains why and where OOFILE diverges from their C++ binding and some of their concepts.

dbTables vs Persistent classes, Refs & Sets:

The ODMG class represents a single instance, with Set and Ref classes used via templates to point to records in the database and collections of records.

OOFILE's dbTable acts as the single class instance, a "factory" for subcollections, a current Set and a Ref all in one. This is accomplished by natural use of the C++ operators, so the operation defines the role.

The main reasons for this were my goals of:
- Avoid templates as many people complain of compiler problems.
- Be able to use C++ without an external preprocessor. To do this and still use subcollections directly in data retrieval, update and search statements, I had to have subcollections as instances of the dbTable. Furthermore, to be able to search by and access related fields, relations have to be mapped by normal c++ pointer syntax.

Database Creation:

The ODMG-93 binding lacks the ability to create a database, whereas this is an essential part of OOFILE.

Additional GUI mapping:

OOFILE includes a number of GUI integration classes for creating "native" browser and edit field classes. It also provides some "superstructure" classes for managing issues such as a primitive report-writer, multiple-page editing dialogs etc.

Relationship specification:

There are a number of ways of specifying relationships and the "OID" fields on a table-by-table basis. Default OIDs will match the situation of a traditional ODBMS but mapping to legacy systems requires we acknowledge the foreign keys over which they currently perform their relations.

This document is best read in accompaniment with the ODMG-93 standard.

Page and Section numbers refer to the standards document.

DIFFERENCES BETWEEN THE ODMG-93 C++ BINDING AND THE OOFILE SIMPLE MODEL WITH SUGGESTIONS OF THINGS WE CAN DO TO OOFILE TO CLOSE THE GAP

P84, S5.1.2 Language Binding

ODMG
Ref-based smart pointers created for each object brought in from a database.
eg:
Ref profP;
profP->grant_tenure();

OOFILE
Methods and attribute access automatically apply to the current current object in class
Professor->grant_tenure();

OOFILE FUTURE
Will allow option of ODMG model.

P87, S5.1.3.1 Object and Literal

ODMG
Object type mapped to c++ class. Embedded classes stored as literals.

OOFILE
Not only do we use persistent base classes for the class, we also have OOFILE bases for the persistent attributes. Embedded classes of any kind are NOT supported.

OOFILE FUTURE
Unlikely to change - we will NOT conform. However, embedded persistent child classes may be allowed. It is more likely a related class will have a storage specifier to bundle it with the parent. Parsing embedded classes with c++ may be difficult. (Consider a different macro eg: EMBEDDED_TABLE).

P87, S5.1.3.4 Collection Classes

ODMG
Provides collections of objects where all attributes of the class are persistent.
eg;
class Ship {...};
Set > Cunard_Line; // persistent collection of type ship.

OOFILE
Only attributes descending from a dbField subclass are persistent.
The object is free to have transient attributes.
eg:
CLASS_TABLE(Ship) .. };
Ship Cunard_Line;

OOFILE FUTURE
Same class and Set level declaration as ODMG but preserves the need for special attributes.

P88, S5.1.3.4

ODMG
C++ constructors and destructors used instead of the ODMG create and delete.

OOFILE
C++ constructors and destructors are left for the programmer to use, eg with a debugging library like MicroQuill's SmartHeap. (ie: operator new and delete are not overloaded by the database). newRecord and saveRecord calls are used eg; Cunard_Line->newRecord();

OOFILE FUTURE
create and delete methods will be allowed as synonyms for newRecord and deleteRecord.

P88, S5.1.3.7 Extents, S5.1.3..8 Keys, S5.1.3.10 Database Administration

ODMG
Does not support these operations in c++.

OOFILE
Fully supports declaration of indexes as part of the database, and creation or opening of existing databases.

P89, S5.1.4.1 Prefix

ODMG
Uses odb_

OOFILE
Uses db

OOFILE FUTURE
???? should we conform to ODMG?