John's ZODB warts
Here is my list of ZODB warts:
- use of closed ranges in BTree containers - Functions such as keys() can take a range, but it is a closed range. In other words, keys(x, y) will give you all keys in the range from x to y, inclusive. Rather, half-open ranges should be used, where y is excluded from the range. The benefits of half-open ranges are well recognized in computer science. See the discussion on zodb-dev. ZODB4 will support half-open ranges as an option, but it will not be the default.
- inconsistent BTree conflict resolution - Two transactions deleting or adding the same key, or changing the value of an existing key, will cause a write conflict. While conservative, the rules are appropriate because these cases are significant (are an exception) in many uses of BTree. However, there is one notable exception to the above rules: if two transactions change the value of an existing key to the same value, there is no write conflict. There are applications of BTree where this case is significant. See the discussion on zodb-dev.
- conflict resolution runs on server rather than client - When using ZEO, application-level conflict resolution will run on the server rather than client. Not having access to the client context complicates configuration, logging, and debugging. For complicated resolution handlers and many clients, the server may become a bottlneck. See the discussion on zodb-dev.
- ZODB relies on Python's "setattr semantics" for marking objects dirty - A persistent object will be marked dirty whenever its __getattr__ method is called. Unfortunately, this includes setting an attribute to its existing value. For example, "foo.bar = foo.bar" will mark foo dirty. Moreover, this affects the use of augmented operators on attributes. See the discussion on zodb-dev.
John's ZODB wishlist
Things I'd like to see added to ZODB:
- ID generation support - This makes multiple sequences of unique ID's available to your application. Without specific support for this in ZODB, it isn't possible to produce such ID's without a high frequency of conflict errors. A patch already exists.