ZODB4 Project Plan
**Note that development on ZODB4 stopped, and resources redirected to ZODB 3.3. This page is of historical interest only.
This plan lists all the features we'd like to include in ZODB4, in rough order of priority. We can guarantee we'll get all the features done. If there's something you are particularly keen on, offer to do it.
Change pickle record format to separate object references
Store object references in their own part of the database record, so that storages don't need to unpickle or otherwise interpret data records to pack or garbage collect.
We will perform some exploratory analysis to decide if this is a win. If we do this, it needs to happen for Zope 3 alpha 2. which will be released on or before March 1, 2003.
Add a datarecord header
This will be used to store meta data.
The initial meta data will be a flag indicating whether data are compressed.
We will perform some exploratory analysis to decide if this is a win. If we do this, it needs to happen for Zope 3 alpha 2. which will be released on or before March 1, 2003.
New transaction API
Implement the new transaction API, which has been discussed in various mailing lists. (XXX Find references.) The new API should allow per-thread policies and global policies. It should have good nested transactions support.
Needs to be done before Zope 3 beta 1 (June 1, 2003)
Multiversion concurrency control
Take advantage of object revisions to avoid read conflicts. Normally a transaction reads the most recent version of every object. When an invalidation messages arrives after a transcaction has begun, this strategy leads to a read conflict when the object is accessed. Instead, use MVCC to read an old version of the object. The transaction can proceed without the read conflict and win if it's a read-only transaction or if it can resolve the eventual conflict.
Needs to be done before Zope 3 beta 1 (June 1, 2003). Because there is some significant risk in this, it should be done as soon as possible.
Design and implement an object cache for the connection that does not rely on special help from the Persistence package. The ZODB3 cache design will be a starting point, but it is unacceptable to have cache-specific slots in the Persistent structure. It should be possible to slot in an arbitrary cache implementation by providing a clean interface between Persistence and Cache via the Connection.
Needs to be done before Zope 3 beta 1 (June 1, 2003).
The conflict resolution mechanism should involve a registry of callables rather than methods on specific classes. The method doesn't get an actual object anyway, so it's a method only for bookkeeping purposes. But associating directly with the class means the class must be loadable on a ZEO server, which isn't always desierable.
Needs to be done before Zope 3 beta 1 (June 1, 2003).
Support persistent objects with slots and properties. Not sure exactly what this task entails beyond __slots__. Maybe nothing.
This is a low priority.
Provide better support for modifying the structure of objects over time. Jim would like this to be eager. I'd like it to be implicit.
This is a low priority.
At least the new Python set type.
This is a low priority.
Improve the C API persistence. One desirable feature is real refcounting for "sticky" persistent objects instead of the one-bit counter currently used.
This is a low priority, but probably makes sense to do some of this as a part of the cache implementation.
Add support to Persistence to support tracking objects read during a transaction to allow databases to support stronger isolation. Not sure how hard it will be to extend the database to detect read-read conflicts.
This is a low priority.
We would remove the hard limit on the connection pool size.
See NotesOnPossibleNewZODBConnectionPool.