>> What I seem to be missing entirely here is why Zope ships Prefix
>> instances at the base ZEO msg level to begin with; maybe it's to call
>> some method I misunderstand (or haven't even bumped into yet <0.6
> When you want to undo something, Zope asks the ZEO server for a list of
> undoable transactions. The resulting list should include only the
> transactions the user is allowed to undo, so Zope passes an object that
> implements __cmp__ to the ZEO server. The object is used to filter
> transactions by the transaction's request path. ZopeUndo.Prefix is one
> such filter.
I figured it was something like that, but I'm still missing it. The code
paths involving methods like undoLog and undoInfo (these are the ones you
have in mind, right?) are so convoluted I've never understood them; it's a
pain figuring out that FileStorage even _has_ an undoInfo method, and the
only docs I've found for that are:
def undoInfo(self, first=0, last=-20, specification=None):
"""Storage API: return undo information."""
That just doesn't mean anything to me -- but then I haven't fixed any bugs
in undo, so I haven't been forced to figure out any of the code implementing
or exposing it yet.
> However, to my knowledge, there are no alternative filters. :-(
If you have to pass a class instance across the wire as some part of
undoInfo's `specification` argument, then the class would need to have the
attribute else ZEO's message-decoding function would just error out. There
are no instances of that attribute anywhere else in ZODB or Zope, and Google
doesn't find any either, so I'd say it's a safe bet that Prefix is indeed
the only one.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org