Object Databases

[Andrew M. Kuchling]

claird at starbase.neosoft.com (Cameron Laird) writes:
> One mystery to me:  why doesn't DB2 get
> more attention?  ...
> I'm bringing it up here because, with all
> the Version 6 goodies, IBM has taken to
> talking about its "object-relational"
> capabilities and "support for object
> orientation".  

The current issue of DB/2 Magazine has an article on the
object-relational features in version 6, and they seem rather
disappointing.  Essentially you can define types that are large
objects, and define methods for each type, but there's no mention of
inheritance.  Methods also apparently can be in SQL or as linked-in C
code; writing methods in Python would be non-trivial.

On the upside, apparently DB/2's documentation is apparently much
better than Oracle's.  I once saw a posting on the Byte.com database
forum from someone at Digital Creations (probably Chris Petrilli);
they were trying to figure out if a library was thread-safe.  The IBM
docs made it clear, but a few hours of poring through the Oracle docs
left things just as murky as before.  

Has anyone written a tool which maps a database schema to a collection
of Python objects?  Something similar to Tangram for Perl
(www.tangram-persistence.org), but for Python?  In Tangram, you write
a schema laying out the objects, and the system then generates SQL
tables to hold them, and automatically handles reading and saving
objects.

Right now my project group is looking at some way to ease the pain of
storing Python objects.  We're aware of these options:

1) Buy an object database (Versant, Matisse, POET, etc.).  Pro: many
powerful ODBMS features; most are quite scalable.  Downsides: we'd
probably have to write a Python interface on top of them; most of the
companies are small companies, and might vanish.

2) ZODB.  Pro: very natural for Python users; very flexible.
Downsides: only one database at a time; doubtful scalability once you
start pushing lots of 5Mb images into it.

3) SQL databases.  Pros: common, well-known technology, from
established companies like Oracle and IBM; lots of other software for
them.  Downsides: storing objects is clunky, requiring writing lots of
boring save/load code, and many joins are needed to read in an object.
We could write something like Tangram to save us from writing boring
code, but that won't help the run-time speed problem.

Anyone had to tackle a similar problem?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I had known him for years in a casual way, but I had never seen very deeply
into him. He seemed to me to have more conscience than is good for any man. A
powerful conscience and no sense of humour -- a dangerous combination.
    -- Robertson Davies, _The Rebel Angels_