How to handle EObject fields which are omitted by EcoreUtil.copy? [message #809115] |
Tue, 28 February 2012 13:52 |
Seref Arikan Messages: 73 Registered: August 2010 |
Member |
|
|
I am sure the word "field" is not really appropriate for the features I'm referring to, but I'll ask for your forgiveness for this inaccuracy.
I am using the Java meta model from Modisco project to create java models of two different sets of Java classes. so I end up with A.xmi and B.xmi from java projects A and B
I have project C which contains the mappings defined in its own Ecore, with references to A and B. The mappings in C must be persisted, so the model in C uses containment.
C is simply a container for mappings, but mappings are not 1 to 1, so I end up creating copies of some objects to make sure they are not removed from one parent when another parent needs to add them.
To achieve this, I create copies of objects and place them under other objects, but some fields are not copied. I can't modify the java meta model, so how do I handle the cases where ECoreUtil.copy does not copy the derived fields etc?
This may sound a bit confusing, and I'm more than happy to clarify, but In general I need something like a weak reference to EObjects that won't change containment of them, but the refences must still be persisted.
Am I completely lost here ?
Kind regards
Seref
|
|
|
Re: How to handle EObject fields which are omitted by EcoreUtil.copy? [message #809174 is a reply to message #809115] |
Tue, 28 February 2012 15:07 |
Seref Arikan Messages: 73 Registered: August 2010 |
Member |
|
|
I've managed to solve my problem for the moment, that is, I've properly configured the referenced models so that a single resource set contains everything that is needed.
This allowed me to use non containment references, and I don't need to use the copy method now.
If someone feels like addressing the use case, it would be great to know though. If I need to use copy on objects from the Java metamodel of Modisco, the problem is still there. The specifics of the problem is: if I make a copy of a ClassDeclaration, the return type of the methods are not fully copied. The return type of methods are represented with TypeAccess, and TypeAccess has type which is of Type. In the copy the type field is always null. The type field is not a derived field either.
Anyway, problem solved for the moment, but the condition still remains a mystery to me
|
|
|
Re: How to handle EObject fields which are omitted by EcoreUtil.copy? [message #809215 is a reply to message #809174] |
Tue, 28 February 2012 15:54 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Seref,
The copier won't copy bidirectional references unless both ends are part
of what's being copied. (Otherwise original objects would be modified
with back reference to the copies.) You need to use something like
copyAll to make sure that all the objects you want copied are copied at
once; this way bidirectional references within the original set of
objects are copied into the new set of objects.
On 28/02/2012 4:07 PM, Seref Arikan wrote:
> I've managed to solve my problem for the moment, that is, I've
> properly configured the referenced models so that a single resource
> set contains everything that is needed.
> This allowed me to use non containment references, and I don't need to
> use the copy method now.
> If someone feels like addressing the use case, it would be great to
> know though. If I need to use copy on objects from the Java metamodel
> of Modisco, the problem is still there. The specifics of the problem
> is: if I make a copy of a ClassDeclaration, the return type of the
> methods are not fully copied. The return type of methods are
> represented with TypeAccess, and TypeAccess has type which is of Type.
> In the copy the type field is always null. The type field is not a
> derived field either.
> Anyway, problem solved for the moment, but the condition still remains
> a mystery to me :)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02598 seconds