[ZODB-Dev] Inconsistent use of ConflictError
Greg Ward
gward@mems-exchange.org
Thu, 16 Aug 2001 15:15:32 -0400
On 16 August 2001, Jim Fulton said:
> I agree with your analysis. Thanks. When you all figure out how this should
> work, I'll check it in. :)
>
> Some comments:
>
> - Serials are binary strings. Think of them as revision ids.
OK. Groping through the code starts to illuminate this. Revised
attribute docstring:
serials : (string, string)
a pair of 8-byte packed strings; these are the serial numbers
(old and new) of the object in conflict. (Serial numbers are
closely related [equal?] to transaction IDs; a ConflictError may
be triggered by a serial number mismatch.)
Only question is whether there should be separate old_serial and
new_serial attrs. Hmmm.
> - There should be a keyword argument/property to indicate read vs write
> conflicts. Maybe we should make subclasses to indicate these and
> other kinds of conflicts.
How about make ReadConflictError an subclass of ConflictError? One
difference would be the default exception message; any others? Is there
information needed by ReadConflict irrelevant for write conflicts?
Or vice-versa -- that would argue for
ConflictError [abstract]
^
|
+-----------+------------+
| |
WriteConflictError ReadConflictError
I'll have to read the code and see if I can figure out which "raise
ConflictError" occurences are really read conflicts. Maybe that will
shed more light.
> - We should define methods, not attributes for getting at bits of data.
Yes, absolutely. (I omitted them for conciseness. ;-)
Preliminary patch forthcoming...
Greg