| [EMFStore]Matching elements by attribute value [message #1637164] |
Thu, 26 February 2015 10:23  |
Eclipse User |
|
|
|
I'd like to understand how EMFStore can be adapted to support the following case.
Let's say that you have a person class that has a unique attribute (let's say Social security number or phone number). Client A creates an entry and Client B does the same. Client A then commits and when Client B updates we get a duplicate entry.
How can we provide special matching rules for identity matching that would allow us to handle case such as above?
Cheers,
Alain
|
|
|
|
|
| Re: [EMFStore]Matching elements by attribute value [message #1661320 is a reply to message #1637371] |
Mon, 09 March 2015 11:25  |
| Eclipse User |
|
|
|
Hi Maximilian,
I'm working with Alain who first asked the question about the ability to guarantee uniqueness of entry. I implemented the ReservationSetModifier like you suggested. It seems working (until the contrary). However, I want to share with you the behavior we are seeing in order to tell us whether it is "normal" behavior or not.
ClientA and ClientB add same child element (for us same name) to a given container, and ClientB first commits.
When ClientA updates, conflict is detected.
If ClientA chooses to "Keep All Their Changes", it ends up with two local changes: creation of the child and deletion of that child. And it will have to commit them (going to a new version number) or to revert them in order to be in sync. If ClientA choose to commit and ClientB updates later on, they are in sync with no problem (meaning "no duplicate" rule is meet).
But if ClientA chooses to "Keep All My Changes", it ends up with more operations to commit: basically all operations involved to create and set the name of the child element plus the deletion of the incoming child element. And it has to commit these operations. When ClientB updates later on, it will be in sync with no problem (no duplicate child).
Note that I called ReservationSetModifier.addFullReservation(parentId) to add a reservation to the container where parentId is its ID.
What do you thing of this?
Cheers,
|
|
|
| Re: [EMFStore]Matching elements by attribute value [message #1682024 is a reply to message #1661320] |
Tue, 17 March 2015 11:05 |
| Eclipse User |
|
|
|
Hi,
sorry for the delayed reply, I was at EclipseCon NA last week.
From you description it is hard for me to say which operations to expect
exactly, however it is generally normal that the operations will differ
for rejecting local (=accepting remote) and rejecting remote (accepting
local) changes.
Is there any specific problem with that or was this just a question to
make sure this is not odd behavior?
Cheers,
Maximilian
Am 09.03.2015 um 16:42 schrieb Aboubacar Kaba:
> Hi Maximilian,
>
> I'm working with Alain who first asked the question about the ability to
> guarantee uniqueness of entry. I implemented the ReservationSetModifier
> like you suggested. It seems working (until the contrary). However, I
> want to share with you the behavior we are seeing in order to tell us
> whether it is "normal" behavior or not.
>
> ClientA and ClientB add same child element (for us same name) to a given
> container, and ClientB first commits.
>
> When ClientA updates, conflict is detected.
> If ClientA chooses to "Keep All Their Changes", it ends up with two
> local changes: creation of the child and deletion of that child. And it
> will have to commit them (going to a new version number) or to revert
> them in order to be in sync. If ClientA choose to commit and ClientB
> updates later on, they are in sync with no problem (meaning "no
> duplicate" rule is meet).
>
> But if ClientA chooses to "Keep All My Changes", it ends up with more
> operations to commit: basically all operations involved to create and
> set the name of the child element plus the deletion of the incoming
> child element. And it has to commit these operations. When ClientB
> updates later on, it will be in sync with no problem (no duplicate child).
>
> Note that I called ReservationSetModifier.addFullReservation(parentId)
> to add a reservation to the container where parentId is its ID.
>
> What do you thing of this?
>
> Cheers,
>
>
--
Maximilian Kögel
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
| Re: [EMFStore]Matching elements by attribute value [message #1690873 is a reply to message #1682024] |
Tue, 31 March 2015 12:47 |
| Eclipse User |
|
|
|
Hi,
It was just a general question to make sure that it's not odd behavior. Because we thought that it doesn't make sense (from the user perspective) that when we accept remote changes, that operation implies local changes to commit. The way around is ok since the user chooses to keep his/her local changes, to be committed later on.
Thanks you very much.
|
|
|
Powered by
FUDForum. Page generated in 0.60577 seconds
Home