[ZODB-Dev] A different sort of ZODB backend

[Jeremy Hylton]

>>>>> "IST" == Itamar Shtull-Trauring <itamar@itamarst.org> writes:

  IST> Consider a PySQLite database with the following schema (see
  IST> http://pysqlite.sourceforge.net/documentation/pysqlite/node10.html
  IST> for the reason I specifically chose PySQLite).

  IST> Objects table has columns: oid, className, dictID [points to
  IST> Dicts table] Lists table: lid, index, valueType, value Dicts
  IST> table: did, attributeType, attribute, valueType,
  IST> valuevalueType, value

  IST> The result is a ZODB storage that can be queried and updated
  IST> using SQL.  You can I think add indexes for specific attributes
  IST> on specific object types as well, but it's too late for me to
  IST> be sure.

  IST> A number of questions:
  IST> 1. Does this make sense at all? (it's 2am :)
  IST> 2. Is ZODB4 stable and usable enough that I can think of making
  IST>    such a
  IST> backend for it, and if so are the interfaces in place that will
  IST> allow this sort of thing?

ZODB's storages don't know much about the objets they store.  The
store() call gets an oid, a revision id, and a pickle.  The only thing
the storage knows about the contents of the pickle is that it can call
referencesf on it.  The ZODB Connection knows how to serialize an
object so that it can be passed to a storage.

So there's a mismatch right now between what you want to do and where
the responsibilities lie in ZODB.  It sounds like we'd need to create
another pluggable layer that controls how ZODB serializes an object
for storage.  I think this would be a good idea.  The implementation
in ZODB4 is evolving so that all the serialization responsibility in
one module.  It seems natural to make this pluggable.

I would say that ZODB4 is stable enough to think about how to do this,
but not to actually do it.  That is, ZODB4 is going to be evolving a
lot in anticipation of an alpha release in December.  I'd be thrilled
if soemone would tackle this project, but there implementation would
probably have to change frequently to accomodate other interface
changes.

Jeremy