[ZODB-Dev] Re: [Zope-Checkins] CVS: ZODB3/ZODB/FileStorage -fspack.py:1.3

[Chris Withers]

Tim Peters wrote:

>>If we want to leave FileStorage raising an exception in this case,
>>perhaps DB.pack could catch and swallow a RedundantPackError?
> 
> How about you and Chris Withers work up a patch that makes you happy and
> leaves his existing code working correctly? 

I'm scared to ask this, but what branch of what in what CVS repository should we 
be lookingto patch against and where are the test cases we need to alter?

> For backward compatibility, I
> bet it's unlikely to show up in future 3.1 or 3.2 releases, but 3.3 is still
> in alpha so still has some flexibility.

Well, with your proposal below, I don't see any backwards compatability 
implications... I mean, even my code from before would still work:

try:

     except FileStorageError,e:
         # don't whinge if the error is only 'cos we've been packed before
         if e.args[0]!='The database has already been packed to a later time\nor 
no changes have been made since the last pack':
             raise

right?

> I'm personally not keen on hiding exceptions by magic:  if I try to pack,
> and pass arguments such that nothing actually changes, it's unclear whether
> I made a mistake or don't care.

Indeed. Most people don't care, but I agree with you.

> actually made a mistake.  So I'd rather make RedundantPackError a subclass
> of FileStorageError (then old code special-casing this particular flavor of
> FileStorageError will continue to catch it); making it a subclass allows an
> easier way to recognize it.

Totally agree...

>     try:
>         whatever
>     except RedundantPackError:
>         pass  # if I don't care about this particular flavor
>     except FileStorageError:
>         panic # but I do care about other forms of FileStorageError

yep

Chris