[ZODB-Dev] Storage API corner cases

[Toby Dickenson]

Ive been adding some unit tests to ZODB based on their coverage of 
DirectoryStorage, and discovered two corner cases where the storage API is 
currently implemented inconsistently......


Firstly, how should getSerial behave when the current revision of an object 
has had its creation undone? The implementation in BaseStorage suggests that 
this case will raise a KeyError, but both FileStorage and BDBFull replace 
this base class method with one that returns the id of the revision in which 
its creation was undone.

A comment in zeoVerify suggests that ZEO is assuming that a KeyError will be 
raised, but its implementation will work with either behavior.

Is getSerial used anywhere else? Is there a reason to require the FileStorage 
behaviour, or should we document both behaviours as acceptable?


Secondly, there are differences between storages in the list of transaction 
returned from undoLog: FileStorage includes some transactions that can never 
be undone because the transaction includes an object for which no previous 
history exists. DirectoryStorage omit these.

This is no problem if undoLog is only used to populate an undo GUI, but could 
lead to problems if undoLog is used for introspection. Is this a problem for 
anyone?