[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