Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Is it safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier?
Is it safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier? [message #660213] Thu, 17 March 2011 12:04 Go to next message
Mario Winterer is currently offline Mario WintererFriend
Messages: 136
Registered: July 2009
Senior Member
Hi!

Should it be safe to call copyReferences() more than once on the same instance of EcoreUtil.Copier?

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).

Thanks,
Mario
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30544
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--
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 Go to previous messageGo to next message
Mario Winterer is currently offline Mario WintererFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30544
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
Previous Topic:Proxy resolval for EAttribute
Next Topic:EMF generated projects don't compile
Goto Forum:
  


Current Time: Tue Oct 15 11:04:13 GMT 2019

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

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

Back to the top