[Maciej Wisniowski, wrestling with _p_resolveConflict]
Because of errors like:
ConflictError: database conflict error (oid 0x0299de, class Products.DCOracle2.DA.Procedure, serial this txn started with 0x035f0726c7bfca88 2005-08-01 08:38:46.816215, serial currently committed 0x035f072fed78ebee 2005-08-01 08:47:55.657582)
and according to: http://www.upfrontsystems.co.za/Members/jean/conflicterrors-explained I've added:
def _p_resolveConflict(self, old, saved, new): print 'old:', old print 'saved:', saved print 'new:', new return new
to SP.py into procedure class (DA.Procedure extends this),
I've started Zope with runzope and there are no 'old':?, 'new':?, 'saved:?' statements at all on the console although other print statements from SP.Procedure are visible.
Maybe these conflict errors I'm dealing with are different kind and are not falling into the correct piece of code or maybe this kind of test (print 'something') is too stupid to see if _p_resolveConflict is executed?
Offhand it looks OK to me, but I don't have any of the code you're using. If you want to dig deeper, look into what happens inside lib/python/ZODB/ConflictResolution.py in function tryToResolveConflict(). If your _p_resolveConflict() were getting called, you would see the print output you coded. Therefore it's not getting called. tryToResolveConflict() is what _tries_ to call it (assuming that for an instance `object` of this type, getattr(object, "_p_resolveConflict", None) returns a non-None value to begin with, which I can't tell for sure from what you've said).