[CDO] Resolve single CDOObject in state CONFLICT [message #425601] |
Wed, 03 December 2008 03:35  |
Eclipse User |
|
|
|
In my current application I have a CDO conform EMF model and a custom RCP
ViewPart (no edit or editor plugins). I'm using CDO 2.0 (I200811270213).
Probably I've overseen the obvious, but I haven't found a clean way to
resolve when a dirty CDOObject in one client is in the conflict state.
I have the following use case:
a) Two clients have made modifications on the same CDOObject.
b) Client A saves (transaction.commit()).
c) Client B gets notified by a CDOSessionInvalidationEvent and indicates in
its viewer that the object now has a conflict (red, bold font).
d) The user of client B selects the conflicting object in the viewer and
invokes a resolve conflict action from the context menu.
e) The resolve conflict action updates the selected CDOObject with the state
CONFLICT.
The problem I haven't found a solution to yet is in e) above. How do I
retrieve the latest, valid version of the CDOObject from the server and get
the CDOView to accept that this CDOObject no longer is in the state
CONFLICT? All ways I've found to reload or read a CDOObject in CONFLICT
state are ignored by the FiniteStateMachine. I would rather not want to
reload the whole CDOView in order to resolve.
Your input would be much appreciated!
Bjoern
|
|
|
|
|
|
|
|
|
Re: [CDO] Resolve single CDOObject in state CONFLICT [message #425671 is a reply to message #425623] |
Thu, 04 December 2008 09:02  |
Eclipse User |
|
|
|
Simon,
Good idea!
That reminds me that I often thought we should have an umbrella concept
for all the possible new, deleted and delta instances. Something like
CDODeltaDescription...
Many signatures could become simpler this way.
Cheers
/Eike
----
http://thegordian.blogspot.com
Simon McDuff schrieb:
> One solution that could work is the following:
>
> - A feature that will rollback and re-apply the changes you made based
> on the latest version of objects. (e.g.: view.reapplyAllChanges());
>
> You could still have issue there.. but in some cases could work.
>
> Simon
>
> Bjoern Sundin wrote:
>> In my current application I have a CDO conform EMF model and a custom
>> RCP ViewPart (no edit or editor plugins). I'm using CDO 2.0
>> (I200811270213).
>>
>> Probably I've overseen the obvious, but I haven't found a clean way
>> to resolve when a dirty CDOObject in one client is in the conflict
>> state.
>>
>> I have the following use case:
>> a) Two clients have made modifications on the same CDOObject.
>> b) Client A saves (transaction.commit()).
>> c) Client B gets notified by a CDOSessionInvalidationEvent and
>> indicates in its viewer that the object now has a conflict (red, bold
>> font).
>> d) The user of client B selects the conflicting object in the viewer
>> and invokes a resolve conflict action from the context menu.
>> e) The resolve conflict action updates the selected CDOObject with
>> the state CONFLICT.
>>
>> The problem I haven't found a solution to yet is in e) above. How do
>> I retrieve the latest, valid version of the CDOObject from the server
>> and get the CDOView to accept that this CDOObject no longer is in the
>> state CONFLICT? All ways I've found to reload or read a CDOObject in
>> CONFLICT state are ignored by the FiniteStateMachine. I would rather
>> not want to reload the whole CDOView in order to resolve.
>>
>> Your input would be much appreciated!
>> Bjoern
>>
|
|
|
Powered by
FUDForum. Page generated in 0.05551 seconds