>>> "Phillip J. Eby" wrote
> There is an error in your patch, however. _prepend should use
> self._objects.insert(0,object), as the way you're doing it now will break
> the _append method. (Because _append is a reference to _objects.append,
> and you're replacing the old _objects with a new list. Subsequent calls to
> _append will append the object to the old _objects list, not the new one
> you've just added.)
Darn. That'll teach me to make a quick patch like this. Still, getting the
feedback is the key thing - I wasn't sure if the approach I was taking was
the right one.
> There is also a *second* problem with your patch, which is more serious and
> less correctable. If a _prepend takes place *during* a commit operation,
> the current implementation of the commit operation will be blown all to
Ugh. Ok, how about then just doing something like not allowing a prepend
once the committings already started?
> Anyway... I'm very much in favor of solving the same problem that you
> are... But it requires a rather more complex patch (so that
> transaction.commit() could deal with prepends during commit) and first we'd
> need to convince Jim that it's the right thing to do. :) (Not only that,
> but he might come up with a better way to do it than prepending...)
He does tend to do that. I'd very much like a way to fix this - at the
moment, the only workaround for me is for SQLSessions to have an entirely
different database connection to themselves.
> Ironically, I'm not sure your problem actually *needs* this fix to be
> solved. You probably need to tie your session object's behavior to an
> earlier transaction event (the "_p_jar.commit()" operation rather than
> tpc_finish()), and you can then be guaranteed that the SQL connection has
> not yet seen a tpc_finish() either.
I'm not sure I understand this - are you suggesting hooking it to the
database connector's commit?
> *My* problem, on the other hand, is that even if I do this, ZODB does not
> allow objects to be _p_jar.commit()ed twice; if you modify an object which
> has already been _p_jar.commit()ed in the same transaction, you will get an
> unresolvable ConflictError (because the ZODB thinks another transaction
> modified the object before you).
Ugh. Nasty nasty. But hey, isn't the whole point of ZPatterns to expose
all the nasty corners of the Zope innards to light?
> Thus, I need to ensure that DataManagers
> which are saving things up 'till a _p_jar.commit() operation, get
> registered ahead of any modification to an object that they might need to
> modify again later. So a fully functional "prepend" capability would be of
> great benefit to ZPatterns, but I'm not sure that your problem actually
> needs it, and your patch, unfortunately, does not achieve it.
Thanks for the feedback - time for me to hit the source code again. :)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -