|
Re: Best practices when updating/copying ecore models? [message #764810 is a reply to message #764755] |
Mon, 12 December 2011 22:12 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Comments below.
On 12/12/2011 8:45 PM, js wrote:
> I am writing an application that needs to update different instances
> of an ecore metamodel defined in my .ecore file.
>
> Assume that two instances of the metamodel M1 and M2 has been created.
> Now I would like to create a third model M3 which is initialized as a
> copy of M1 and based on some rules content from M2 is copied to M3.
>
> This could be started doing:
>
> M3 copy = EcoreUtil.copy(M1);
>
> But the copy will not contain:
>
> 1) derived features
Derived features are (assumed to be) computed from things that are not
derived. There's shouldn't be a need to copy them...
> 2) Not changeable feature
Can't be populated so can't be copied...
> ...
>
> I have created my own copier:
>
>
>
> public class MyCopier extends Copier {
> private static final long serialVersionUID = 1L;
>
> /**
> * Returns a copy of the given eObject.
> *
> * @param eObject
> * the object to copy.
> * @return the copy.
> */
> @Override
> public EObject copy(EObject eObject) {
> if (eObject == null) {
> return null;
> }
>
> EObject copyEObject = createCopy(eObject);
> put(eObject, copyEObject);
> EClass eClass = eObject.eClass();
> for (int i = 0, size = eClass.getFeatureCount(); i < size; ++i) {
> EStructuralFeature eStructuralFeature =
> eClass.getEStructuralFeature(i);
> // if (eStructuralFeature.isChangeable() &&
> // !eStructuralFeature.isDerived()) {
> // if (eStructuralFeature.isChangeable()) {
> if (eStructuralFeature instanceof EAttribute) {
> copyAttribute((EAttribute) eStructuralFeature, eObject,
> copyEObject);
> } else {
> EReference eReference = (EReference) eStructuralFeature;
> if (eReference.isContainment()) {
> copyContainment(eReference, eObject, copyEObject);
> }
> }
> }
> copyProxyURI(eObject, copyEObject);
> return copyEObject;
> }
> }
>
>
> which solves the above problems. But I am runnnig into other problems
> (eg. with bi-directional lists that are not contained in the model
> etc.) and am starting to get the feeling that this in not the right
> approach.
You have to copy both ends at once using something like copyAll. Think
about it, if the copy referred to a non-copied objects, the original
non-copied object would be modified to point back at the copy. That
can't generally be a good thing.
> Is this kind of operation (copying/updating ecore instances) not a
> well known problem that is better handled by some framework instead of
> hacking the build in copy functionality?
No, it should work well. The questions to ask is why is something
marked derived when in fact it is important information that can't be
computed from other information? Also, how is it possible to copy
something that can't be changed (and hence eSet won't work for it)?
Note that multi-valued features don't actually guard against
modification, but if you're relying on that, you shouldn't mark then as
not changeable...
>
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03563 seconds