Object Database (ODBMS) for Python

Patrick K. O'Brien pobrien at orbtech.com
Fri Aug 29 14:02:07 EDT 2003


"Paul D. Fernhout" <pdfernhout at kurtz-fernhout.com> writes:

> My biggest issue with OO databases (including "a Smalltalk image"
> for that matter) in general is that the definition of objects
> changes over time, and on a practical basis, it might be needed to
> support multiple definitions of a class with the same name
> simultaneously if supporting a broad range of applications and
> somehwo resolve version issues. The Pointrel System in itself
> doesn't solve that problem either, but it also doesn't have that
> problem built in at the core, since its main storage type is just an
> arbitrary binary string. I mainly added the Python object support
> just because "pickle" made it easy and fun to do the basics, and I
> thought that a limited level of transparent support might make it
> more appealing to Pythonistas and provide some extra easy
> expanability if people really wanted to easily store typed
> information as oposed to strings. (ALthough I think it could also
> bring headaches if people have PyPerSyst level expectations for
> object storage and retrieval when I support something more like a
> Newton soup entry..)

Schema evolution and schema migration are tough issues.  In some ways
things are simpler with PyPerSyst, since all objects reside in memory
at all times.  What that means is that there is no need to write
utilities that "touch" all of your instances.  When you start a
PyPerSyst database, the entire thing is unpickled, which calls
__setstate__ on all your objects.  So migrating to a new schema is
simply a matter of dumping the database, stopping the engine,
replacing the schema, and restarting the engine.

Making sure that your schema does the right thing is another matter.
I'm still working on that.  Ideally you would want your class
definitions to themselves be a persisted schema that could only be
modified by transactions that would generate the appropriate
__getstate__ and __setstate__ methods to properly handle the changes.
So a distant goal is to have a PyPerSyst application that handles
schema evolution and migration for other PyPerSyst databases.  Doesn't
that sound like fun?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------




More information about the Python-list mailing list