Why is Chandler not using ZODB?

This page documents why the Repository development team decided not to use ZODB after investigating it.

Bill Seitz asked: "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...)"

Andi Vajda answered:

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 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.

Further discussions/digressions from the original page have been moved here.