Home » Modeling » EMF » copying a set of eobjects
|
| Re: copying a set of eobjects [message #424193 is a reply to message #424191] |
Mon, 20 October 2008 12:41   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
Christian Saad wrote:
> Hi,
>
> I'd like to duplicate a custom set of interconnected EObjects. The
> reason for this is that one should be able to store some selected
> parts of a model as templates to separate files from where they can be
> reimported into other models.
So that they can be copied and changed later I guess...
> This means, that references between objects in the selected set should
> also be present between the copied instances while connections to
> object nots in the set should be removed. EcoreUtil.copyAll does not
> work for me, since it also creates copies of the referenced objects
> instead of linking them directly.
Not sue I understand the last part.
>
> e.g. there are two objects connected through a reference A -> B. What
> I need now is A' -> B', instead copyAll returns A'->B'' (B'' is not
> part of the return list) and a lonely B'.
Does A contain B. Are you copying A and B with a single copyAll call
that's providing a list containing A and B?
>
> My question is: Is there any !elegant! way to achieve the desired
> behaviour since now I'm using a CopyToClipboardCommand combined with
> an iteration on the result collection that cuts references to external
> objects which works but is obviously very ugly.
Even if copy/copyAll doesn't do exactly what you want, I imagine there's
nothing you couldn't accomplish by specializing EcoreUtil.Copier
itself. Look closely at how the utility methods use it. Note that the
Copier itself is a map and hence the keySet of that map will be your A,
B whatever, and the values will be A', B', whatever'.
>
> Thanks for your help,
> Chris
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: copying a set of eobjects [message #424231 is a reply to message #424193] |
Tue, 21 October 2008 08:31 |
Christian Saad
Messages: 39
Registered: July 2009 |
Member |
|
|
Hi Ed,
thanks for your support. You are right, it does make a difference if the
reference is of the containment type. The references between objects are
replicated in the copy just as they were in the original but containments
are not. I'll try to pick up your suggestion of extending the copier
itself.
Regards,
Chris
Ed Merks wrote:
> Christian,
> Comments below.
> Christian Saad wrote:
>> Hi,
>>
>> I'd like to duplicate a custom set of interconnected EObjects. The
>> reason for this is that one should be able to store some selected
>> parts of a model as templates to separate files from where they can be
>> reimported into other models.
> So that they can be copied and changed later I guess...
>> This means, that references between objects in the selected set should
>> also be present between the copied instances while connections to
>> object nots in the set should be removed. EcoreUtil.copyAll does not
>> work for me, since it also creates copies of the referenced objects
>> instead of linking them directly.
> Not sue I understand the last part.
>>
>> e.g. there are two objects connected through a reference A -> B. What
>> I need now is A' -> B', instead copyAll returns A'->B'' (B'' is not
>> part of the return list) and a lonely B'.
> Does A contain B. Are you copying A and B with a single copyAll call
> that's providing a list containing A and B?
>>
>> My question is: Is there any !elegant! way to achieve the desired
>> behaviour since now I'm using a CopyToClipboardCommand combined with
>> an iteration on the result collection that cuts references to external
>> objects which works but is obviously very ugly.
> Even if copy/copyAll doesn't do exactly what you want, I imagine there's
> nothing you couldn't accomplish by specializing EcoreUtil.Copier
> itself. Look closely at how the utility methods use it. Note that the
> Copier itself is a map and hence the keySet of that map will be your A,
> B whatever, and the values will be A', B', whatever'.
>>
>> Thanks for your help,
>> Chris
>>
|
|
| |
| Re: copying a set of eobjects [message #424239 is a reply to message #424238] |
Tue, 21 October 2008 12:46 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Chris,
The idea of the copier is to produce a clone of the containment tree,
not just a copy of one specific object, much like the way DOM supports
cloning an Element. So the idea is to walk the whole containment tree
and create a copy of each object in it while copying over the attribute
values. Those copies are stored in a map. As a second pass, each
copied object is revisited again to copy the cross references. This is
deferred so that when a reference to an object is copied, if that
referenced object was copied, the reference will be to the copy and not
to the original. Bidirectional references are not copied because
copying those would result in modifications to the original object and
obviously producing a copy should have no side-effect on the original.
Christian Saad wrote:
> Hi again,
>
> a quick update: I removed the containment specific handling from the
> copier (in the copy(...) and copyAll() method) and at the first
> impression, it seems to do the trick.
> However, I did test only a few easy cases so there may be side effects
> and, after all, the programmers surely had a reason to implement it
> the way it was implemented. Just out of curiosity, I'd like to ask why
> this approach was chosen in the case I'm missing something important
> here.
>
> Thanks,
> Chris
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: copying a set of eobjects [message #424244 is a reply to message #424239] |
Tue, 21 October 2008 15:41 |
Christian Saad
Messages: 39
Registered: July 2009 |
Member |
|
|
Hi Ed,
I understand now the difficulties in replicating references which should
of course not alter the original model. However, I'm still not quite sure
why bidirectional references, be they standard references or containment
relationships, shouldn't be restored if *both* participants are in the
input set given to copyAll() since the bidirectional relationship could be
restored between the two copies without sideeffects on the original model
elements.
Regards,
Chris
Ed Merks wrote:
> Chris,
> The idea of the copier is to produce a clone of the containment tree,
> not just a copy of one specific object, much like the way DOM supports
> cloning an Element. So the idea is to walk the whole containment tree
> and create a copy of each object in it while copying over the attribute
> values. Those copies are stored in a map. As a second pass, each
> copied object is revisited again to copy the cross references. This is
> deferred so that when a reference to an object is copied, if that
> referenced object was copied, the reference will be to the copy and not
> to the original. Bidirectional references are not copied because
> copying those would result in modifications to the original object and
> obviously producing a copy should have no side-effect on the original.
> Christian Saad wrote:
>> Hi again,
>>
>> a quick update: I removed the containment specific handling from the
>> copier (in the copy(...) and copyAll() method) and at the first
>> impression, it seems to do the trick.
>> However, I did test only a few easy cases so there may be side effects
>> and, after all, the programmers surely had a reason to implement it
>> the way it was implemented. Just out of curiosity, I'd like to ask why
>> this approach was chosen in the case I'm missing something important
>> here.
>>
>> Thanks,
>> Chris
>>
|
|
|
| Re: copying a set of eobjects [message #424245 is a reply to message #424244] |
Tue, 21 October 2008 16:03 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Chris,
Note the useOriginalReferences flag and also note that bidirectional
reference copying is guarded just as you expect. If both ends are
within the copy fine, but outside the copy, they are ignored.
C. Saad wrote:
> Hi Ed,
>
> I understand now the difficulties in replicating references which
> should of course not alter the original model. However, I'm still not
> quite sure why bidirectional references, be they standard references
> or containment relationships, shouldn't be restored if *both*
> participants are in the input set given to copyAll() since the
> bidirectional relationship could be restored between the two copies
> without sideeffects on the original model elements.
>
> Regards,
> Chris
>
> Ed Merks wrote:
>
>> Chris,
>
>> The idea of the copier is to produce a clone of the containment tree,
>> not just a copy of one specific object, much like the way DOM
>> supports cloning an Element. So the idea is to walk the whole
>> containment tree and create a copy of each object in it while copying
>> over the attribute values. Those copies are stored in a map. As a
>> second pass, each copied object is revisited again to copy the cross
>> references. This is deferred so that when a reference to an object
>> is copied, if that referenced object was copied, the reference will
>> be to the copy and not to the original. Bidirectional references are
>> not copied because copying those would result in modifications to the
>> original object and obviously producing a copy should have no
>> side-effect on the original.
>
>
>> Christian Saad wrote:
>>> Hi again,
>>>
>>> a quick update: I removed the containment specific handling from the
>>> copier (in the copy(...) and copyAll() method) and at the first
>>> impression, it seems to do the trick.
>>> However, I did test only a few easy cases so there may be side
>>> effects and, after all, the programmers surely had a reason to
>>> implement it the way it was implemented. Just out of curiosity, I'd
>>> like to ask why this approach was chosen in the case I'm missing
>>> something important here.
>>>
>>> Thanks,
>>> Chris
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:44:47 GMT 2024
Powered by FUDForum. Page generated in 0.02866 seconds |
] 
Search
Help
Register
Login
Home
