[ZODB-Dev] Loading objects directly by OID

[Jeremy Hylton]

>>>>> "GW" == Greg Ward <gward@mems-exchange.org> writes:

  GW> IOW, it's in the storage now -- it's either a result of the
  GW> existing codebase or some ZODB oddity.

I think the important question is:  How was the dangling reference
created?  I assume the missing object existed at some point and was
somehow removed while there was still a reference to it.

  >> What attributes does a WaferDescription have?  Is one a
  >> DimensionCollection?  In what ways can the methods of a
  >> WaferDescription modify its state?  Is there any code that
  >> modifies a WaferDescription, but isn't a method?

  GW> Well, in the extreme abstraction I packaged up and mailed out
  GW> today, both WaferDescription and DimensionCollection have no
  GW> instance attributes, no class attributes, no methods, no
  GW> superclasses, and no subclasses:
  [...]
  GW> Even in this extremely simplified version of our system, the
  GW> anomalous behaviour persists: this storage has a reference to an
  GW> object apparently not in the storage.

Well, sure, you can't load the missing object regardless of the class
definition you use.  The invalid reference is already in the database.

  GW> I *think* this simplification rules out the possibility of a
  GW> __setstate__() somewhere accidentally creating the mystery
  GW> object.

I don't understand what you mean.  There is no mystery object, just a
reference to non-object.

  GW> * DimensionCollection should be a singleton; this is the class
  GW>     that represents the seven fundamental dimensions of the SI
  GW>     (length, mass, time, current, temperature, substance amount,
  GW>     and light intensity); if there is ever more than one
  GW>     DimensionCollection instance in our database, something is
  GW>     wrong.  We recently discovered that this was exactly the
  GW>     case, so I wrote a script to replace all the accidental
  GW>     duplicates with the One True Instance.  The fact that one
  GW>     lone DimensionCollection was not caught by this script was
  GW>     my tip-off to this referenced-but-not-loadable object.

This certainly sounds unusual and it modified instances of exactly the
object we're unable to load.

How did you "replace all the accidental duplicates"?  Where the
duplicates removed by a pack or some other mechanism?  Is the oid that
we can't load the oid of one of the accidental duplicates?

Jeremy