using _p_resolveConflict on Folderish object
Hi all - I'm trying to resolve ConflictErrors in my Product. It might be relevant that the product is derived from 'Folder'. I created a '_p_resolveConflict' function that prints the three state parameters, 'old', 'saved' and 'new'. I was surprised to see that the printed representation of the three states was identical: the data inside 'PR(...) was the same for every subobject. Also, 'oldstate == savedstate' was true, but not 'oldState == newState' or 'oldState is savedState'. I would like to know what's going on here. For example, if 'oldState == newState', can I safely assume that newState is correct and there's no need to merge changes (which changes?) between oldState and savedState? Now follows the printed state, in case that may help explaining this. The 'Feed' insances in the folder are named feed_###. state == { 'feed_view__doc__': 'dummy', '__ac_local_roles__': {'wilm': ['Owner']}, 'index_html__doc__': 'dummy', '_owner': (['acl_users'], 'wilm'), 'cookie_name': 'DF_cat_skin', 'title': '', 'id': 'cat', 'nav_frame__doc__': 'dummy', 'feed_902912': PR(164726636 ('\x00\x00\x00\x00\x00\x00\r\x0e', ('Products.DogFeed.DFFeed', 'Feed'))), 'feed_070984': PR(164727028 ('\x00\x00\x00\x00\x00\x00\r\x0f', ('Products.DogFeed.DFFeed', 'Feed'))), [...] '_objects': ( {'meta_type': 'DogFeed RSS Feed', 'id': 'feed_902912'}, {'meta_type': 'DogFeed RSS Feed', 'id': 'feed_070984'}, [...] ) } Thanks. - Willem
Just in case you haven't yet make sure to read this: <http://www.zope.org/Members/jim/ZODB/ApplicationLevelConflictResolution> To answer your question, savedState and newState are the ones competing for "final" state. Do not get confused by the (badly chosen) parameter names ;-). Your job is to resolve this conflict by e.g. intermediateState = merge(oldState, savedState) finalState = merge(intermediateState, newState) return finalState Stefan On Sun, 29 Dec 2002, Willem Broekema wrote:
Hi all - I'm trying to resolve ConflictErrors in my Product. It might be relevant that the product is derived from 'Folder'.
I created a '_p_resolveConflict' function that prints the three state parameters, 'old', 'saved' and 'new'.
I was surprised to see that the printed representation of the three states was identical: the data inside 'PR(...) was the same for every subobject. Also, 'oldstate == savedstate' was true, but not 'oldState == newState' or 'oldState is savedState'.
I would like to know what's going on here. For example, if 'oldState == newState', can I safely assume that newState is correct and there's no need to merge changes (which changes?) between oldState and savedState?
Stefan H. Holek wrote:
To answer your question, savedState and newState are the ones competing for "final" state. Do not get confused by the (badly chosen) parameter names ;-). Your job is to resolve this conflict by e.g.
intermediateState = merge(oldState, savedState) finalState = merge(intermediateState, newState) return finalState
I understand that, in theory. :-) In practise, I saw that oldState and savedState were equal. I don't see the conflict. Therefore, I don't know how to 'merge' the states. Can I assume there is no real conflict then, and return the newState? BTW, I made a typo in my previous post: willem wrote:
'oldstate == savedstate' [...] I would like to know what's going on here. For example, if 'oldState == newState', can I safely assume that newState is correct and there's no need to merge changes (which changes?) between oldState and savedState?
I meant 'oldState == savedState' here, referring to the part above. Not 'oldSate == newState'. - Willem
On Sun, 29 Dec 2002, Willem Broekema wrote:
Stefan H. Holek wrote:
To answer your question, savedState and newState are the ones competing for "final" state. Do not get confused by the (badly chosen) parameter names ;-). Your job is to resolve this conflict by e.g.
intermediateState = merge(oldState, savedState) finalState = merge(intermediateState, newState) return finalState
I understand that, in theory. :-)
Let me add that depending on your situation, *both* savedState and newState may be "correct". If, say, the conflict is triggered by two threads simultaneously adding new objects to your Folder, you will want the final state to contain the subobjects from both these threads (states).
In practise, I saw that oldState and savedState were equal. I don't see the conflict. Therefore, I don't know how to 'merge' the states.
There is no need to merge equal states.
Can I assume there is no real conflict then, and return the newState?
Only if oldState == savedState == newState. Stefan
Stefan H. Holek wrote:
In practise, I saw that oldState and savedState were equal. I don't see the conflict. Therefore, I don't know how to 'merge' the states.
There is no need to merge equal states.
Can I assume there is no real conflict then, and return the newState?
Only if oldState == savedState == newState.
In my case, oldState == savedState != newState. Your last statement implies there was some real conflict here, yet you also indicate there's nothing to merge. As far as I understand it, the changes that led to newState were based on oldState. Because that foundation seems not to have changed, there's no inconsistency: newState if just fine. I don't see what could or should be done in this case to "resolve" the "conflict", other than just ignoring it and returning newState. Thanks so far, - Willem
On Sun, 29 Dec 2002, Willem Broekema wrote:
In my case, oldState == savedState != newState. Your last statement implies there was some real conflict here, yet you also indicate there's nothing to merge.
Ugh, savedState != newState is exactly the conflict we are talking about. The params should probably have been named newState1 and newState2. Both are equally good (or bad) results of the current transaction. The naming may have led you to the assumption that newState is somehow preferable to savedState. It is not. newState is what you wanted to commit, savedState is what another thread wanted to commit. Note also that it's not about selecting a state to return, but about actually computing a new one, given two equally valid, conflicting, new states, and the state you started from for reference.
As far as I understand it, the changes that led to newState were based on oldState. Because that foundation seems not to have changed, there's no inconsistency: newState if just fine.
The changes that led to savedState very likely were based on oldState as well. Point is that savedState is just as "fine" an outcome. This is what you are resolving after all. Stefan
On Sunday 29 December 2002 6:42 pm, Willem Broekema wrote:
I understand that, in theory. :-)
In practise, I saw that oldState and savedState were equal. I don't see the conflict. Therefore, I don't know how to 'merge' the states.
Can I assume there is no real conflict then, and return the newState?
Yes, in theory. Out of the two transactions that ZODB thinks are competing, it it possible that one of them was caused simply by a self._p_changed (or equivalent) and there really was no 'state' change.
In practise, I saw that oldState and savedState were equal.
I think it would be wise to investigate the cause of this no-change transaction before assuming this observation is correct. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Willem Broekema wrote at 2002-12-29 15:32 +0100:
I'm trying to resolve ConflictErrors in my Product. It might be relevant that the product is derived from 'Folder'. I have seen a good documentation about conflict resolution with a precise description of what the different parameters mean and what you may and may not change.
Unfortunately, I do no longer know where. I would use Google to find out again.... Dieter
participants (4)
-
Dieter Maurer -
Stefan H. Holek -
Toby Dickenson -
Willem Broekema