...

...

"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. :) Anthony