Hello all -
Two short things:
First, caching is still screwed up for us. I'm using CVS
from a week or so ago, after all the createTable stuff was
added. (Due to my changes mentioned in another message about
defaultOrder sorting stuff, I haven't tried updating to
the latest, but I show no diffs that would seem to fix this...)
I still only encounter this bug when destroying an object,
since destroy() makes no check for existance in the cache.
So our oblivious fix (ignoring why things still aren't being
cached) is to add:
if self._SO_instanceCache.has_key(self.id):
del self._SO_instanceCache[self.id]
at the end of destroy().
Second, very bad things happen if I instantiate an object
with an id that doesn't exist in the database (ie,
Product(43) ). It is instantiated fine, but when an
attribute is accessed it hangs python entirely. The cause of
the hang is unclear at this point, and concerns me, but at a
minimum we need a way to check if an object exists! Our
feeling is that instantiating a non-existant ID should
throw an exception immediately, but alternatively (or as the
implementation of throwing an exception), a function to make
sure the id is valid in the database should be created.
Probably should be in the Connection classes, since all SQL
should ideally be over there..
Now that I look through the code again, _SO_autoInit()
should be taking care of this, but that only happens when
attrs are accessed, and that's where the fatal hang is
happening anyways.
Summary:
a new connection-level function, tentatively named
'isValidID'. _init should call this (?), and raise a new
exception before caching etc.
Thoughts?
- Luke
|
