[Dev] (db policy) transparent persistence

Andy Dent dent at oofile.com.au
Tue Nov 26 17:13:36 PST 2002


At 12:38 -0800 26/11/2002, David McCusker wrote:
>What does transparent object persistence mean?
>
>It means persistent content is mainly the attributes of some
>collection of objects, or of subobjects recursively embedded in other
>top level persistent objects.  Interacting with this content involves
>using normal Python objects.  Database updates merely involve modifying
>these objects and then committing the database.

I'm a big fan of at least some degree of transparency - the OOFILE API was
evolved with discussion on a similar design list to this one (back in
92-93) and has as much transparency as could be achieved in cross-platform
C++ pre-STL. (Note: to understand the following code examples you need to
know that OOFILE just compiles as pure C++ and doesn't use any database
preprocessor, using operator overloading for member access and search
specification instead).

ie: class declarations use base classes to indicate persistence of the
class and members (you can have non-persistent member variables in a
persistent class).


class StudentT : public dbTable {
   OOFILE_METHODS(Student)
   // only macro used, declares some inline functions for easier
programming, not essential

   dbChar  Name;
   dbShort  Level;
};

StudentT students;  // use a global in this example, would probably be
member in Document

The base constructors of these fields automatically hook the fields up to
the class and you could also declare a persistent class by dynamically
creating fields. The key to this flexibility is the two stage schema -
creating a persistent object defines an OOFILE Schema. Until you create
another dbTable object, all dbField descendants are linked to the
last-created dbTable. It's a simple idiom that allows for array definition
and other dynamic fields, not just a compile-time schema.

When a database connection is opened with that object, the schema is sealed
and translated to an appropriate dBase, c-tree Plus or other schema.

The big issue I had with the ODMG C++ database binding, and the assumptions
I've seen since in other object-relational layers, is that everything
happens via navigation from some known root.

(Hence gross hacks like using raw SQL to find the root, reifying that into
an object then starting to use OO paradigms.)



More information about the Dev mailing list