Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EcoreUtil.copy problem with CDO(Copied set ends up in eSettings rather than associated with the attribute name.)
EcoreUtil.copy problem with CDO [message #1718359] Tue, 22 December 2015 21:25 Go to next message
Paul C. Brown is currently offline Paul C. BrownFriend
Messages: 18
Registered: October 2013
Junior Member
I am converting an existing application to use CDO. The application uses EcoreUtil.copy in several places. The copy worked fine before converting to CDO (i.e. before altering the genmodel). Now when I copy an element, if the element has a set associated with an attribute (my attribute is ownedBaseElements), the copied element has a null value for the attribute, and the actual set is an entry under eSettings. The original element had a null under that eSettings entry.

Can someone explain to me why this is happening and tell me how to fix it?

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1718370 is a reply to message #1718359] Wed, 23 December 2015 05:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Paul,

Has the generated code for the getter or setter been specialized in some
way? If so, GenModel's Feature Delegation choice is relevant. To
ensure that your specialized logic is not bypassed, Feature Delegation
should be Reflective not Dynamic.


On 22/12/2015 10:25 PM, Paul C. Brown wrote:
> I am converting an existing application to use CDO. The application
> uses EcoreUtil.copy in several places. The copy worked fine before
> converting to CDO (i.e. before altering the genmodel). Now when I copy
> an element, if the element has a set associated with an attribute (my
> attribute is ownedBaseElements), the copied element has a null value
> for the attribute, and the actual set is an entry under eSettings. The
> original element had a null under that eSettings entry.
>
> Can someone explain to me why this is happening and tell me how to fix
> it?
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1718435 is a reply to message #1718370] Wed, 23 December 2015 15:56 Go to previous messageGo to next message
Paul C. Brown is currently offline Paul C. BrownFriend
Messages: 18
Registered: October 2013
Junior Member
Ed,

Thanks. I saw a reference that said the opposite (can't remember where it was). Let me try that.

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1718464 is a reply to message #1718435] Thu, 24 December 2015 07:37 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Paul,

Hopefully I'm not wrong, but definitely look at the specialized logic
and make sure it's being called.

On 23/12/2015 4:56 PM, Paul C. Brown wrote:
> Ed,
>
> Thanks. I saw a reference that said the opposite (can't remember where
> it was). Let me try that.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1719246 is a reply to message #1718464] Wed, 06 January 2016 14:44 Go to previous messageGo to next message
Paul C. Brown is currently offline Paul C. BrownFriend
Messages: 18
Registered: October 2013
Junior Member
Ed,

I am a little confused about what code is supposed to be generated when Reflective is the feature generation choice. For example, I have a model relation commonNameLiteral that is Derived, Transient, and Volatile. Yet when I generate the code (configured for CDO) I get:

/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public Literal getCommonNameLiteral() {
return (Literal)eGet(CRLPackage.Literals.ELEMENT__COMMON_NAME_LITERAL, true);
}

I expected some kind of placeholder code here. Of course I can mark this as NOT generated and put my own code in, but I am concerned that other things will not be working. In particular, there seems to be some assumption that the eGet with these arguments will return the commonNameLiteral. If I simply rewrite the getCommonNameLiteral() method, this is not going to make the eGet() call work if called elsewhere. What am I missing?

[Updated on: Wed, 06 January 2016 14:45]

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1719253 is a reply to message #1719246] Wed, 06 January 2016 15:45 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Paul,

Yes, sorry I got it exactly backward. For Dyanmic delegation, an eGet
is generated that calls the generated accessor, so you have proper hooks
where to specialize the code. For Reflective delegation, which is more
efficient because it completely bypasses the generated accessors, there
are no such hooks. Does that leave you with your original problem?

(I'll be away until next Monday, so follow up help won't be quick.)

On 06/01/2016 3:44 PM, Paul C. Brown wrote:
> Ed,
>
> I am a little confused about what code is supposed to be generated
> when Rflective is the feature generation choice. For example, I have a
> model relation commonNameLiteral that is Derived, Transient, and
> Volatile. Yet when I generate the code (configured for CDO) I get:
>
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public Literal getCommonNameLiteral() {
> return
> (Literal)eGet(CRLPackage.Literals.ELEMENT__COMMON_NAME_LITERAL, true);
> }
>
> I expected some kind of placeholder code here. Of course I can mark
> this as NOT generated and put my own code in, but I am concerned that
> other things will not be working. In particular, there seems to be
> some assumption that the eGet with these arguments will return the
> commonNameLiteral. If I simply rewrite the getCommonNameLiteral()
> method, this is not going to make the eGet() call work if called
> elsewhere. What am I missing?
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1719257 is a reply to message #1719253] Wed, 06 January 2016 15:57 Go to previous messageGo to next message
Paul C. Brown is currently offline Paul C. BrownFriend
Messages: 18
Registered: October 2013
Junior Member
Yes, I think it does. However, to be fair, I migrated non-CDO implementations that had my @generated NOT methods to CDO implementations. It is possible that the presence of my @generated Not methods prevented the generation of essential logic for CDO. I wish we had some documentation for the intended design patterns here. I'm going to go back and regenerate from scratch (without my @generated NOT methods) and compare the results with what I was using before. I'll report the results back here.

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1719764 is a reply to message #1719257] Mon, 11 January 2016 21:21 Go to previous messageGo to next message
Paul C. Brown is currently offline Paul C. BrownFriend
Messages: 18
Registered: October 2013
Junior Member
Ed,

I thought I had updated this, but my posting did not appear. I removed all my @generated NOT customizations, regenerated, and then modified the get<X>, basicGet<X> and set<X> methods for my derived, transient, and volatile references. Copy now works.

It sure would be useful if the generated code for these three methods generated placeholders rather than finished code. It was less than clear that all three need to be updated (I thought the get<X> methods would call the basicGet<X> methods behind the scenes). How should I make this request (i.e. to what project)?

Report message to a moderator

Re: EcoreUtil.copy problem with CDO [message #1719844 is a reply to message #1719764] Tue, 12 January 2016 14:50 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Paul,

You can open a bugzilla against the EMF project's Tools component. It's
not so likely to get attention without an associated Gerrit contribution.


On 11/01/2016 10:21 PM, Paul C. Brown wrote:
> Ed,
>
> I thought I had updated this, but my posting did not appear. I removed
> all my @generated NOT customizations, regenerated, and then modified
> the get<X>, basicGet<X> and set<X> methods for my derived, transient,
> and volatile references. Copy now works.
>
> It sure would be useful if the generated code for these three methods
> generated placeholders rather than finished code. It was less than
> clear that all three need to be updated (I thought the get<X> methods
> would call the basicGet<X> methods behind the scenes). How should I
> make this request (i.e. to what project)?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:generating JUnit 4 tests
Next Topic:[Core] ItemDescriptors not displayed in the properties sheet page
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Apr 25 04:41:07 GMT 2024

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly