Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMFStore]Matching elements by attribute value
[EMFStore]Matching elements by attribute value [message #1637164] Thu, 26 February 2015 15:23 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
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 #1637371 is a reply to message #1637164] Thu, 26 February 2015 17:31 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 253
Registered: July 2009
Senior Member
Hi Alain,

you can influence the conflict detection behavior with a
ReservationSetModifier:
http://download.eclipse.org/emfstore/releases_14/javadoc/org/eclipse/emf/emfstore/internal/server/conflictDetection/ReservationSetModifier.html
Also see this previous question on the topic:
https://www.eclipse.org/forums/index.php/t/794219/
Hope this helps!

Cheers,
Maximilian

Am 26.02.2015 um 16:23 schrieb Alain Picard:
> 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


--
Maximilian Kögel

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
Re: [EMFStore]Matching elements by attribute value [message #1638039 is a reply to message #1637371] Fri, 27 February 2015 01:13 Go to previous messageGo to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
Thanks so much for the info.

Alain
Re: [EMFStore]Matching elements by attribute value [message #1661320 is a reply to message #1637371] Mon, 09 March 2015 15:25 Go to previous messageGo to next message
Aboubacar Kaba is currently offline Aboubacar KabaFriend
Messages: 9
Registered: March 2015
Junior Member
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 15:05 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 253
Registered: July 2009
Senior Member
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 16:47 Go to previous message
Aboubacar Kaba is currently offline Aboubacar KabaFriend
Messages: 9
Registered: March 2015
Junior Member
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.
Previous Topic:[Teneo] Import XMI EMF Model
Next Topic:[ECP] Additional label alignment option "Top"?
Goto Forum:
  


Current Time: Sat Mar 28 19:17:59 GMT 2020

Powered by FUDForum. Page generated in 0.02160 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top