|
Re: EcoreUtil.Copier does not keep order of lists [message #899554 is a reply to message #899549] |
Wed, 01 August 2012 12:02 |
Ed Merks 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 #899672 is a reply to message #899556] |
Wed, 01 August 2012 18:25 |
Ed Merks 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/
|
|
|
|
Powered by
FUDForum. Page generated in 0.04490 seconds