[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


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).
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to