Home » Modeling » EMF » Is it safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier?
|
| Re: Is it safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier? [message #660254 is a reply to message #660213] |
Thu, 17 March 2011 14:57   |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000900050007080405080806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mario,
Comments below.
Mario Winterer wrote:
> Hi!
>
> Should it be safe to call copyReferences() more than once on the same
> instance of EcoreUtil.Copier?
Copying the references more than once would be pointless.
>
> My tests show, that it is NOT safe in EMF 2.5.0, but as the javadoc
> does not explicitely say something like "do not call more than once!",
> I'm not sure if it should work (so it's a bug) or not (so maybe the
> javadoc should be clarified).
It does say
* When all the objects have been copied,
* the client should call {@link #copyReferences copyReferences}
* to copy the {@link #copyReference appropriate} {@link
EObject#eCrossReferences cross references}.
So either it's pointless (a no op-op) to call it more than once, or
you've called it once, copied some more objects, and then wanted
references for those hooked up, so you called it a second time. But of
course then you've not followed the explicit statement about "*when all
the object have been copied* the client should call copyReferences"
because you called it once before that was true.
What were you hoping to achieve. Note that it's particular important in
the case of bidirectional references that all the copies be created
before you try to copy the references because bidirectional references
will be hooked up only in the case that both the referencing object and
the referenced object have been copied. Otherwise original objects
would refer back to copies, thereby modifying the state of the originals...
>
> Thanks,
> Mario
--------------000900050007080405080806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mario,<br>
<br>
Comments below.<br>
<br>
Mario Winterer wrote:
<blockquote cite="mid:ilssvd$ooj$1@news.eclipse.org" type="cite">Hi!
<br>
<br>
Should it be safe to call copyReferences() more than once on the same
instance of EcoreUtil.Copier?
<br>
</blockquote>
Copying the references more than once would be pointless.<br>
<blockquote cite="mid:ilssvd$ooj$1@news.eclipse.org" type="cite"><br>
My tests show, that it is NOT safe in EMF 2.5.0, but as the javadoc
does not explicitely say something like "do not call more than once!",
I'm not sure if it should work (so it's a bug) or not (so maybe the
javadoc should be clarified).
<br>
</blockquote>
It does say <br>
<br>
* When all the objects have been copied, <br>
* the client should call {@link #copyReferences copyReferences} <br>
* to copy the {@link #copyReference appropriate} {@link
EObject#eCrossReferences cross references}.<br>
<br>
So either it's pointless (a no op-op) to call it more than once, or
you've called it once, copied some more objects, and then wanted
references for those hooked up, so you called it a second time. But of
course then you've not followed the explicit statement about "<b>when
all the object have been copied</b> the client should call
copyReferences" because you called it once before that was true.<br>
<br>
What were you hoping to achieve. Note that it's particular important
in the case of bidirectional references that all the copies be created
before you try to copy the references because bidirectional references
will be hooked up only in the case that both the referencing object and
the referenced object have been copied. Otherwise original objects
would refer back to copies, thereby modifying the state of the
originals...<br>
<blockquote cite="mid:ilssvd$ooj$1@news.eclipse.org" type="cite"><br>
Thanks,
<br>
Mario
<br>
</blockquote>
</body>
</html>
--------------000900050007080405080806--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Is it safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier? [message #660394 is a reply to message #660254] |
Fri, 18 March 2011 09:51 |
Mario Winterer
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Ed!
Thanks for your quick response!
In our case it's the latter: First some objects are copied, then we call copyReferences() and afterwards we do the same once again (or even more often) for other objects. A final "copyReferences" is done at the end.
The entire code is spread upon several classes following the strategy pattern, all sharing a common copier but each going its own way. In the beginning, there was no intermedate invocation of "copyReferences()" (as the javadoc of EcoreUtil.Copier suggests), but then some code required the references to get copied at an early stage and so we simply added a "copyReferences" in between which seemed to be much simpler than redesigning the entire component (knowing that this is a shady solution, though).
In other words: The whole thing is a poor workaround for a design weakness (or bug)!
As our models evolve and we're adding additional features (like feature maps etc.), our "solution" does not work correctly any more (each additional invocation of copyReferences redoubles the feature map entries in the destination feature map).
You're right: If I take the javadoc literally, copyReferences has to be called only once and at the end. Maybe the addition "Calling {@link #copyReferences copyReferences} more than once might cause unpredicted results." would make it even clearer...
In the meantime, I've improved our workaround by a subclass of EcoreUtil.Copier that ensures that no references are copied twice (knowing that this does not cover the case in which copyReferences is called after copying an object having references to objects that are copied later on).
Thanks,
Mario
|
|
|
| Re: Is it safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier? [message #660447 is a reply to message #660394] |
Fri, 18 March 2011 13:27 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mario,
Comments below.
Mario Winterer wrote:
> Hi Ed!
>
> Thanks for your quick response!
>
> In our case it's the latter: First some objects are copied, then we
> call copyReferences() and afterwards we do the same once again (or
> even more often) for other objects. A final "copyReferences" is done
> at the end.
So that's just not going to produce consistent results. The references
copied earlier might refer to original objects (in the non-bidirectional
case) or might omit references (in the bidirectional case) which later
should have referenced copies produced later.
> The entire code is spread upon several classes following the strategy
> pattern, all sharing a common copier but each going its own way. In
> the beginning, there was no intermedate invocation of
> "copyReferences()" (as the javadoc of EcoreUtil.Copier suggests), but
> then some code required the references to get copied at an early stage
> and so we simply added a "copyReferences" in between which seemed to
> be much simpler than redesigning the entire component (knowing that
> this is a shady solution, though).
The issue then is that this early stage code might well see a different
state than is correct at the end of the whole process...
>
> In other words: The whole thing is a poor workaround for a design
> weakness (or bug)!
> As our models evolve and we're adding additional features (like
> feature maps etc.), our "solution" does not work correctly any more
> (each additional invocation of copyReferences redoubles the feature
> map entries in the destination feature map).
Yes, nothing checks the state of the object to ensure that things aren't
being down twice...
>
> You're right: If I take the javadoc literally, copyReferences has to
> be called only once and at the end. Maybe the addition "Calling {@link
> #copyReferences copyReferences} more than once might cause unpredicted
> results." would make it even clearer...
>
> In the meantime, I've improved our workaround by a subclass of
> EcoreUtil.Copier that ensures that no references are copied twice
> (knowing that this does not cover the case in which copyReferences is
> called after copying an object having references to objects that are
> copied later on).
Yes, you'll potentially have cases of references that are missing or
references that aren't to the copies.
>
> Thanks,
> Mario
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 01:08:44 GMT 2024
Powered by FUDForum. Page generated in 0.02170 seconds |
] 
Search
Help
Register
Login
Home
