Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EcoreUtil.Copier does not keep order of lists
EcoreUtil.Copier does not keep order of lists [message #899549] Wed, 01 August 2012 11:50 Go to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
Messages: 117
Registered: February 2012
Senior Member
Hello,

I have an ecore model consisting of a diagram (container), objects and relations.
The objects have a reference attribute to a relation and the relation has a list of objects that are part of the relation.
Note that both the objects and the relations are contained by the diagram (in a list).

Lets say I want to copy two objects and a relation (containing references to these objects in its list), using EcoreUtil.Copier.
This results in the copies, where the objects refer to the new relation and the new relation contains a list of the newly copied objects.

The only problem is that the order of the list of objects of the copied reference is not defined.
Sometimes it is correct and sometimes it is wrong. (I suppose it depends on the order of objects in the HashMap of the Copier).

Is this expected behavior of Copier, or is it a bug and should I report it?

Note: I have added code to properly order copied lists to match the original order (for lists that have the ordered ecore attribute set) to prevent this problem/bug.

Regards,
Maarten
Re: EcoreUtil.Copier does not keep order of lists [message #899554 is a reply to message #899549] Wed, 01 August 2012 12:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Maarten,

Comments below.

On 01/08/2012 1:50 PM, Maarten Bezemer wrote:
> Hello,
>
> I have an ecore model consisting of a diagram (container), objects and
> relations.
> The objects have a reference attribute to a relation and the relation
> has a list of objects that are part of the relation.
> Note that both the objects and the relations are contained by the
> diagram (in a list).
>
> Lets say I want to copy two objects and a relation (containing
> references to these objects in its list), using EcoreUtil.Copier.
> This results in the copies, where the objects refer to the new
> relation and the new relation contains a list of the newly copied
> objects.
>
> The only problem is that the order of the list of objects of the
> copied reference is not defined.
> Sometimes it is correct and sometimes it is wrong. (I suppose it
> depends on the order of objects in the HashMap of the Copier).
I don't really see how that's possible. Copier.copyReference walks the
list is adds the copies as it proceeds; order doesn't depend on the
copier's map, which is just used keep track of the mapping from
originals to copies..
>
> Is this expected behavior of Copier, or is it a bug and should I
> report it?
No. If you have a reproducible test case, definitely file a bugzilla.
>
> Note: I have added code to properly order copied lists to match the
> original order (for lists that have the ordered ecore attribute set)
> to prevent this problem/bug.
It's hard to imagine that something that's been so long in use would
have such a glaring problem...
>
> Regards,
> Maarten


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EcoreUtil.Copier does not keep order of lists [message #899556 is a reply to message #899554] Wed, 01 August 2012 12:14 Go to previous messageGo to next message
Maarten Bezemer is currently offline Maarten BezemerFriend
Messages: 117
Registered: February 2012
Senior Member
> > The only problem is that the order of the list of objects of the
> > copied reference is not defined.
> > Sometimes it is correct and sometimes it is wrong. (I suppose it
> > depends on the order of objects in the HashMap of the Copier).
> I don't really see how that's possible. Copier.copyReference walks the
> list is adds the copies as it proceeds; order doesn't depend on the
> copier's map, which is just used keep track of the mapping from
> originals to copies..

Problem is it does not walk the list.
It walks only containing lists (which is the one in the diagram). The two objects get added to the reference list, because it walks the objects attributes. Hence my thought that the order depends on the order of the Copier HashMap.

From EcoreUtil.Copier:
public void copyReferences()
{
  for (Map.Entry<EObject, EObject> entry  : entrySet())
  {
    ...
  }
}


> > Is this expected behavior of Copier, or is it a bug and should I
> > report it?
> No. If you have a reproducible test case, definitely file a bugzilla.

It is part of a much bigger application, so before I spend time in creating a test case, I thought to ask here first... Smile

> > Note: I have added code to properly order copied lists to match the
> > original order (for lists that have the ordered ecore attribute set)
> > to prevent this problem/bug.
> It's hard to imagine that something that's been so long in use would
> have such a glaring problem...

Exactly my thoughts...

[Updated on: Wed, 01 August 2012 12:17]

Report message to a moderator

Re: EcoreUtil.Copier does not keep order of lists [message #899672 is a reply to message #899556] Wed, 01 August 2012 18:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Marteen,

Comments below.

On 01/08/2012 2:14 PM, Maarten Bezemer wrote:
>> > The only problem is that the order of the list of objects of the >
>> copied reference is not defined.
>> > Sometimes it is correct and sometimes it is wrong. (I suppose it >
>> depends on the order of objects in the HashMap of the Copier).
>> I don't really see how that's possible. Copier.copyReference walks
>> the list is adds the copies as it proceeds; order doesn't depend on
>> the copier's map, which is just used keep track of the mapping from
>> originals to copies..
>
> Problem is it does not walk the list.
Yes it does, in copyReferences.
> It walks only containing lists (which is the one in the diagram).
It walks the containment tree first so that it can establish which
objects are copied and their correspondence...
> The two objects get added to the reference list, because it walks the
> objects attributes.
All the object's features.
> Hence my thought that the order depends on the order of the Copier
> HashMap.
>
> From EcoreUtil.Copier:
>
> public void copyReferences()
> {
> for (Map.Entry<EObject, EObject> entry : entrySet())
That just walks the pairs of orginals and their copies so that it can
transfer the feature values from original to the copy; the order in
which this is done is irrelevant in terms of how the values of a
multivalued feature is walked.
> {
> ...
> }
> }
>
>
>> > Is this expected behavior of Copier, or is it a bug and should I >
>> report it?
>> No. If you have a reproducible test case, definitely file a bugzilla.
>
> It is part of a much bigger application, so before I spend time in
> creating a test case, I though I ask here first... :)
Is there something special about the model's implementation of the
feature for which the order isn't being preserved? That seems more
likely to be the cause. You could set a breakpoint in copyReference for
when that feature is copied; but I guess you did that and in those cases
it works properly...
>> > Note: I have added code to properly order copied lists to match the
>> > original order (for lists that have the ordered ecore attribute
>> set) > to prevent this problem/bug.
>> It's hard to imagine that something that's been so long in use would
>> have such a glaring problem...
>
> Exactly my thoughts...
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EcoreUtil.Copier does not keep order of lists [message #899985 is a reply to message #899672] Fri, 03 August 2012 10:44 Go to previous message
Maarten Bezemer is currently offline Maarten BezemerFriend
Messages: 117
Registered: February 2012
Senior Member
I found an error in my implementation: the list had the derived attribute set... :S

After some debugging I noticed that the copyReference() method contains code that is very similar to my 'workaround'... So I checked why that code was not reached... Wink

Thanks for your help!
Previous Topic:[CDO] Deprecated config elements in cdo-server.xml ?
Next Topic:saving references in dynamically created emf
Goto Forum:
  


Current Time: Fri Mar 29 13:32:42 GMT 2024

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

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

Back to the top