[Z3-sqlos] obj.destroySelf() broken in sqlos
Sidnei da Silva
sidnei at awkly.org
Wed Oct 20 20:20:08 CEST 2004
On Wed, Oct 20, 2004 at 08:06:00PM +0200, Andrew Bennetts wrote:
| Using destroySelf on an SQLOS instance will cause the transaction to fail
| due to an exception, because sqlos will attempt to call obj.sync() on a now
| invalid object.
|
| Currently, sqlos just intercepts writes to the dirty flag, and adds objects
| to a list to be synced at the end of the transaction, but never removes from
| this list (except at the end of a transaction). I see that SQLObject's
| implementation of destroySelf invokes
| "self._connection.cache.expire(self.id, self.__class__)" to keep it's
| object cache consistent... perhaps sqlos should use that cache, rather than
| manage its own seperate one?
It uses that cache... except it has one per thread *wink*. The list of
objects to be synced is not a cache.
| I'll try to write a test-case to demonstrate this soon.
|
| A nasty workaround is to add this to the SQLOS class:
|
| def sync(self):
| if self._SO_obsolete:
| return
| SQLObject.sync(self)
|
| But I don't believe this is the correct fix.
Sync is called when the transaction commit()'s now. I think that
checking for _SO_obsolete there would be fine. Notice that I replaced the
handling from inside the transaction manager by firing an event so not
to have duplicated code.
Unfortunately we didn't had edge cases like this so far, and it would
never happen in our application: delete is completely disabled
there. It's nice though that the bugs are popping up.
I would make the fix myself, but I prefer to wait for your testcase.
--
Sidnei da Silva <sidnei at awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher
* radix would rather go see glyph than Linus :-)
<Viiru> radix: Why?
More information about the z3-sqlos
mailing list