Open Source Applications Foundation

[Dev] history of ZODB use/problems/removal?

Andi Vajda Tue, 21 Oct 2003 11:28:08 -0700 (PDT)


The reasons are multiple but none are exactly a ZODB show stopper. Ultimately
it was a decision I made based on the constraints of the project.

  - ZODB is a python object database. While Chandler is written in python, I
    wanted its data model to be independant of any language in particular and
    needed it therefore to be more constrained than python's.

  - By making the data model more constrained and by controlling it there are
    many things that are made easier, in particular queries, interactions with
    RDF, bi-directional referential integrity, access control, garbage
    collection, etc...

  - There are also a number of requirements the Chandler designers created for
    the repository that are made easier to implement if we control the actual
    representation of the data and constrain the data model, such as
    replication, remote access, shared access, threaded transaction model,
    etc...

  - When I started working on this project in May, the repository was late,
    very late, and the project was stalled because of that. I felt I could get
    something usable for the project to resume much faster if I started a
    data model implementation from scratch and persisted it using Sleepycat's
    Berkeley dbxml and Berkeley db.

Today, the Chandler repository is not really so much an object database as an
item XML database combined with large collections of references directly
stored in Berkeley DB.
Chandler persistence is grafted on top of whatever language binding is chosen
to operate it (currently only Python is supported). By that I mean that a
programmer's python instances are never persisted in the Chandler repository,
only specific attribute values the programmer intended for Chandler.

The trade-off for these decisions and design choices is a somewhat steeper
learning curve for programmers expecting a real object database like ZODB.
My hope is that this trade-off is well worth the gains.

Andi..

On Tue, 21 Oct 2003, John Anderson wrote:

> Hi Bill:
>
> ZODB didn't handle all of our needs, and rather than modifying ZODB,
> Andi (who's in charge of the database) decided to write his own thing.
> You should probably ask Andi for his reasons. In my discussions with
> various programmers concerning ZODB, it seems like they are reluctant to
> spend much time learning it and would rather go invent something new.
>
> John
>
> Bill Seitz wrote:
>
> > Are there any references online (wiki pages, list archives) discussing
> > the decision to eliminate ZODB, and a short explanation of what's
> > being used instead? (Or maybe there are multiple non-ZODB back-ends
> > possible, all hidden behind RAP...)
> >
> > I guess I'm just curious in terms of lessons learned for other
> > situations calling for a persistence engine...
> >
> > (I've tried searching various places and couldn't find anything that
> > seemed directly relevant...)
> >
> >
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> >
> > Open Source Applications Foundation "Dev" mailing list
> > http://lists.osafoundation.org/mailman/listinfo/dev
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>