| [EMFStore] customizing date equality [message #1192503] |
Sun, 17 November 2013 11:06  |
Eclipse User |
|
|
|
My application uses a custom Date class and when two EMFStore clients
attempt to commit the same date to the same EAttribute in the same
EObject, EMFStore sees it as a conflict. See the attached screenshot.
I thought it would work find, because my custom Date class implements
public boolean equals(Object obj) {}
How does EMFStore determine whether there is a conflict between two
attributes?
$cott
|
|
|
| Re: [EMFStore] customizing date equality [message #1194042 is a reply to message #1192503] |
Mon, 18 November 2013 04:59  |
| Eclipse User |
|
|
|
Hi Scott,
I'm afraid I need to speak a bit more verbosely on this :)
The conflict detection of EMFStore basically works by recording all
changes via operations.
When a client with local changes has an update pending, conflict
resolution will fetch the remote changes and will read both the incoming
as well as the local operations. Out of these operations the conflict
detection will make reservations for each model element that has been
modified by an operation. A reservation has the form: ID of the model
element, feature name and in case of references potentially opposites.
What happens in your case now is, that a conflict is created because
there is an incoming as well as a local change that both
make the same reservation (the syncDate attribute), therefore EMFStore
decides that a conflict must exist. What is missing here, is a
fine-grained resolution of the conflict, i.e. we would need to look at
the conflict and check all involved operations. If we see that both
operations come to the same result, we would be able to neglect the
conflict. But this ain't currently the case.
Essentially we had this working in the past before refactoring the whole
conflict detection/resolution mechanism, but it seems to have got lost.
I therefore opened up a ticket to address the issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=421947
It think we can solve this for 1.1 together with some other changes
which are relevant for you (Bug 421417: SaveStateChangeObserver part of
API, Bug 421944: command stack notifications issue). Meanwhile you may
want to update to 1.0.3 which should fix the issue of not being able to
share a project that has its contents in an external resource.
Cheers,
Edgar
> My application uses a custom Date class and when two EMFStore clients
> attempt to commit the same date to the same EAttribute in the same
> EObject, EMFStore sees it as a conflict. See the attached screenshot.
>
> I thought it would work find, because my custom Date class implements
>
> public boolean equals(Object obj) {}
>
> How does EMFStore determine whether there is a conflict between two
> attributes?
>
> $cott
>
--
Edgar Mueller
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
Powered by
FUDForum. Page generated in 0.03709 seconds
Home