Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy((for my specific use-case, not suggesting a change to EMF))
Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653417] Wed, 09 February 2011 17:03 Go to next message
Ben Tenne is currently offline Ben TenneFriend
Messages: 50
Registered: October 2009
Member
I noticed that the Javadoc comment for EcoreUtil.copy(EObject) states that it "Returns a self-contained copy of the eObject". I then observed that EAttributes (non-primitive) are not duplicated in the copy, but the existing instances in the source object hierarchy are referenced.

This is consistent with a passage in The Book: "...the values themselves are not copied. So if an EObject has a mutable object as the value of a non-primitive attribute, that mutable object can be changed by code that is interacting with either the original or the copied EObject."

In my case, I'm not using primitives or any special types to back attributes. Neither am I using non-containments. My attributes are always one of: String, Integer, Boolean Double, BigInteger, BigDecimal, XMLGregorianCalendar, Duration and FeatureMap. Given that FeatureMaps are dealt with as a special case during copying, the only one of these that is mutable is XMLGregorianCalendar. Therefore, if I can alter the copy behaviour to explicitly create copies of XMLGregorianCalendars, then I get a truly self-contained copy of my root EObject.

I was thinking of doing this by extending EcoreUtil and overriding copyAttribute(EAttribute eAttribute, EObject eObject, EObject copyEObject). The code change would simply check to see if the attribute is an XMLGregorianCalendar and clone it. Alternatively, I could see if the attribute object's class implements Cloneable and use that as an indication that it's probably mutable, and clone it (harmless, either way).

Does this sound reasonable?

Cheers,
Ben.
Re: Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653513 is a reply to message #653417] Thu, 10 February 2011 03:58 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Am 09.02.2011 18:03, schrieb Ben Tenne:
> I noticed that the Javadoc comment for EcoreUtil.copy(EObject) states that it "Returns a self-contained copy of the eObject". I then observed that EAttributes (non-primitive) are not duplicated in the copy, but the existing instances in the source object hierarchy are referenced.
>
> This is consistent with a passage in The Book: "...the values themselves are not copied. So if an EObject has a mutable object as the value of a non-primitive attribute, that mutable object can be changed by code that is interacting with either the original or the copied EObject."
>
> In my case, I'm not using primitives or any special types to back attributes. Neither am I using non-containments. My attributes are always one of: String, Integer, Boolean Double, BigInteger, BigDecimal, XMLGregorianCalendar, Duration and FeatureMap. Given that FeatureMaps are dealt with as a special case during copying, the only one of these that is mutable is XMLGregorianCalendar. Therefore, if I can alter the copy behaviour to explicitly create copies of XMLGregorianCalendars, then I get a truly self-contained copy of my root EObject.
>
> I was thinking of doing this by extending EcoreUtil and overriding copyAttribute(EAttribute eAttribute, EObject eObject, EObject copyEObject). The code change would simply check to see if the attribute is an XMLGregorianCalendar and clone it. Alternatively, I could see if the attribute object's class implements Cloneable and use that as an indication that it's probably mutable, and clone it (harmless, either way).
>
> Does this sound reasonable?
Yes ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653557 is a reply to message #653417] Thu, 10 February 2011 09:03 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30559
Registered: July 2009
Senior Member
Ben,

Comments below.

Ben Tenne wrote:
> I noticed that the Javadoc comment for EcoreUtil.copy(EObject) states
> that it "Returns a self-contained copy of the eObject". I then
> observed that EAttributes (non-primitive) are not duplicated in the
> copy, but the existing instances in the source object hierarchy are
> referenced.
Attribute values are effectively assumed to be things that generally
have no modifiable state and can be shared...
>
> This is consistent with a passage in The Book: "...the values
> themselves are not copied. So if an EObject has a mutable object as
> the value of a non-primitive attribute, that mutable object can be
> changed by code that is interacting with either the original or the
> copied EObject."
>
> In my case, I'm not using primitives or any special types to back
> attributes. Neither am I using non-containments. My attributes are
> always one of: String, Integer, Boolean Double, BigInteger,
> BigDecimal, XMLGregorianCalendar, Duration and FeatureMap. Given that
> FeatureMaps are dealt with as a special case during copying, the only
> one of these that is mutable is XMLGregorianCalendar. Therefore, if I
> can alter the copy behaviour to explicitly create copies of
> XMLGregorianCalendars, then I get a truly self-contained copy of my
> root EObject.
>
> I was thinking of doing this by extending EcoreUtil and overriding
> copyAttribute(EAttribute eAttribute, EObject eObject, EObject
> copyEObject). The code change would simply check to see if the
> attribute is an XMLGregorianCalendar and clone it. Alternatively, I
> could see if the attribute object's class implements Cloneable and use
> that as an indication that it's probably mutable, and clone it
> (harmless, either way).
>
> Does this sound reasonable?
Yes.
>
> Cheers,
> Ben.
Previous Topic:Serialization of EMF data to Relational DB
Next Topic:EObject.eIsSet and default value
Goto Forum:
  


Current Time: Thu Oct 24 01:42:03 GMT 2019

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

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

Back to the top