[ZODB-Dev] Inconsistent use of ConflictError

[Greg Ward]

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