Home » Modeling » EMF » Changing EType of an EAttribute @ runtime
| Changing EType of an EAttribute @ runtime [message #416601] |
Thu, 07 February 2008 09:26  |
Eclipse User |
|
|
|
Hi guys,
Before talking about my problem i'll give a brief background.
I have an EMF model (M1 say) for which i have model and edit code
generated. Now, M1 is volatile, meaning addition of new attributes can
happen or change of existing attributes can happen on M1.
Keeping the volatility in mind, i let the user add new attributes to the
model (M1) and the ReflectiveProviders take care of bringing them on the
UI.
In brief, @ run-time i create a copy of my M1 EPackage, and add any new
attributes to that in memory EPackage (M2 say). And any further processing
is done through the M2 EPackage.
the problem:
now the problem comes when there is a change in data-type of an existing
attribute. (lets consider Integer to Float). Although in the M2 EPacakge
the existing attribute's data-type is changed from Integer to Float... if
i do an eSet on the attribute (after data-type change) setters from the
generated code are invoked which still take in an Integer and hence i get
a ClassCastException.
when i do an eSet or an eGet for a feature thru my in memory M2 EPackage
... i don't want the existing generated code to be invoked. coz its
obsolete ... is there any way to achieve this.
this is the most brief i could get.
cheers,
Chetan Kumar
|
|
|
| Re: Changing EType of an EAttribute @ runtime [message #416603 is a reply to message #416601] |
Thu, 07 February 2008 10:13  |
| Eclipse User |
|
|
|
Hi Chetan,
I see two possible issues:
1. I'm not sure how you're copying your M1 EPackage. But, if whatever
you're doing yields another EPackage that uses your generated M1
factory, then it will create instances of your generated implementation
classes.
Try calling getEFactoryInstance() to obtain the factory from your M2
package. If it's just an instance of EFactoryImpl, not your generated
factory class, this isn't the problem.
2. Dynamic EMF does not support changing the model after you've started
instantiating it. EObjectImpl allocates typed setting holders for its
features, so it's just not possible to add, remove, or change the
attributes of classes that have already been instantiated. If this is
what you're trying to do, it just won't work.
It might be possible for you to derive an EObject implementation that is
more tolerant of changes in the model (for example, by using a map,
instead of an array, to store settings). But, I'd still expect you'll
face some nasty problems, such as how to update existing instances when
a feature changes or is removed, which is why we've never done that.
One other potential problem I see looming is that you shouldn't really
be using two different packages with the same namespace URI. Having
multiple copies, even identical, of metadata tends to get people in trouble.
Cheers,
Dave
Chetan Kumar wrote:
> Hi guys,
>
> Before talking about my problem i'll give a brief background.
> I have an EMF model (M1 say) for which i have model and edit code
> generated. Now, M1 is volatile, meaning addition of new attributes can
> happen or change of existing attributes can happen on M1.
>
> Keeping the volatility in mind, i let the user add new attributes to
> the model (M1) and the ReflectiveProviders take care of bringing them on
> the UI. In brief, @ run-time i create a copy of my M1 EPackage, and add
> any new attributes to that in memory EPackage (M2 say). And any further
> processing is done through the M2 EPackage.
>
> the problem:
> now the problem comes when there is a change in data-type of an
> existing attribute. (lets consider Integer to Float). Although in the M2
> EPacakge the existing attribute's data-type is changed from Integer to
> Float... if i do an eSet on the attribute (after data-type change)
> setters from the generated code are invoked which still take in an
> Integer and hence i get a ClassCastException.
>
> when i do an eSet or an eGet for a feature thru my in memory M2
> EPackage .. i don't want the existing generated code to be invoked. coz
> its obsolete ... is there any way to achieve this.
>
> this is the most brief i could get.
>
> cheers,
> Chetan Kumar
>
>
>
|
|
|
| Re: Changing EType of an EAttribute @ runtime [message #416604 is a reply to message #416601] |
Thu, 07 February 2008 10:23 |
| Eclipse User |
|
|
|
Hi Chetan,
We don't recommend changing a class after creating an instance of it.
This may work in some scenarios, but will probably cause problems in others.
Here's a list of newsgroup posts that address this issue (certainly
there are more posts). As you will see, the common solutions for this
are to model wildcards features (like the ones available in XML schema),
and to dynamically extend an existing class.
"dynamic attributes" from 2/22/2006 5:32 AM
"Dynamically extending the Ecore model?" from 6/29/2007 3:15 AM
"dynamic extension of model" from 7/10/2007 11:16 AM
Cheers,
Marcelo
Chetan Kumar wrote:
> Hi guys,
>
> Before talking about my problem i'll give a brief background.
> I have an EMF model (M1 say) for which i have model and edit code
> generated. Now, M1 is volatile, meaning addition of new attributes can
> happen or change of existing attributes can happen on M1.
>
> Keeping the volatility in mind, i let the user add new attributes to
> the model (M1) and the ReflectiveProviders take care of bringing them on
> the UI. In brief, @ run-time i create a copy of my M1 EPackage, and add
> any new attributes to that in memory EPackage (M2 say). And any further
> processing is done through the M2 EPackage.
>
> the problem:
> now the problem comes when there is a change in data-type of an
> existing attribute. (lets consider Integer to Float). Although in the M2
> EPacakge the existing attribute's data-type is changed from Integer to
> Float... if i do an eSet on the attribute (after data-type change)
> setters from the generated code are invoked which still take in an
> Integer and hence i get a ClassCastException.
>
> when i do an eSet or an eGet for a feature thru my in memory M2
> EPackage .. i don't want the existing generated code to be invoked. coz
> its obsolete ... is there any way to achieve this.
>
> this is the most brief i could get.
>
> cheers,
> Chetan Kumar
>
>
>
|
|
| |
| Re: Changing EType of an EAttribute @ runtime [message #416610 is a reply to message #416607] |
Thu, 07 February 2008 12:10 |
| Eclipse User |
|
|
|
Chetan Kumar wrote:
> Hi Dave,
>
> 1. i create a deep copy of my existing M1 package in memory, keep the
> same nsURI but register the M2 EPackage for that nsURI. there by i am
> able to have 2 EPackages for the same nsURI. I checked that factory
> instance part, objects created from M2 package use factory of type
> EFactoryImpl.
Hi again,
I can think of just a few possibilities:
1. The classes in your copied package extend the corresponding ones in
the original. Then, the EFactoryImpl implementation of create() will
intentionally instantiate the generated base.
2. The copy of the package is still returning the generated factory,
yielding the generated implementations. Apparently you've already ruled
this one out.
3. The generated factory is being obtained directly, not from the
package. This can be done by registering a factory override via the
org.eclipse.emf.ecore.factory_override extension point. This wraps the
registered EPackage.Descriptor for the factory with a special descriptor
that yields the factory directly. However, if you're replacing the
package registration in the registry, this shouldn't be a problem.
What I'm really thinking you should do is put a breakpoint in your
M1FactoryImpl.create(EClass) method and see exactly what's invoking it.
By the way, having two EPackages for the same namespace URI still seems
questionable to me, but if you constrain your usage sufficiently, I
suppose it could be possible to avoid any problems.
Cheers,
Dave
|
|
| | | | | |
| Re: Changing EType of an EAttribute @ runtime [message #416699 is a reply to message #416696] |
Wed, 13 February 2008 09:05 |
| Eclipse User |
|
|
|
Chetan Kumar wrote:
>
> Well, that was the reason why we went to extending rather than cloning.
> looks like we're back then.
Hi Chetan,
You could consider base types that declare no features (or only the
features that you know won't change). Basically you don't get to have it
both ways: you can't say type B inherits type A's features (that's part
of what makes them type compatible, after all) and then change those
features.
Cheers,
Dave
|
|
|
Goto Forum:
Current Time: Mon Sep 15 11:55:28 EDT 2025
Powered by FUDForum. Page generated in 0.04788 seconds |
Home