[ZODB-Dev] Typechecking oid in getitem

Christian Reis kiko at async.com.br
Mon May 19 14:16:26 EDT 2003


On Mon, May 19, 2003 at 11:28:31AM -0400, Jeremy Hylton wrote:
> > Hmmm. So would the correct fix be to implement API so the storage can
> > inform what type the OID should be? I could implement something like:
> > 
> >     storage.getOIDType()
> > 
> > that returned a TypeObject. Are other storage authors against this
> > change? It would make sanity checking easier AFAICT. 
> 
> I'm not all that keen on adding safety belts to catch these errors.  It
> just doesn't seem Pythonic.
> 
> Do you know what you got a TypeError unsliceable object in the original
> error report?  Maybe it's possible to fix the storage so that it raises
> a more useful error message.

Fair enough. By reading the code, I *think* the correct place to handle
this is inside FileStorage, then. We in theory could do the check inside
fsIndex.py but I don't think it's the right way to go.

OTOH, to be 100% correct we'd need to check the oid in *all* references
to _index[oid]. So AFAICT we have two choices:

    a) Change FileStorage to check the oid on all `relevant' methods before
        sending it into fsIndex. This includes:

        - _load
        - _loada
        - loadSerial
        - modifiedInVersion
        - store
        - restore
        - _getSerial
        - _trasactionalUndoRecord 
        - history
        - lastSerial

    b) Change fsIndex to validate the oid in:
        - __getitem__
        - get
        - __setitem__
        - has_key
        - __contains__

Even though more involved, I think a) is more correct, since fsIndex
isn't public, but what do others think? 

Note that many places we already do try: except KeyError, so maybe it
would be a matter of changing KeyError to (KeyError, TypeError) in these
places?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL



More information about the ZODB-Dev mailing list