[Edapt] Proxy related issues on deserialization [message #1729268] |
Tue, 12 April 2016 09:20  |
Eclipse User |
|
|
|
I have model content (call it Instance A) that, due to a perverse project, must resolve proxies (using non-containment EReferences) to a separate EMF model that can only exist in memory (Instance B). Both Instance A and Instance B use the same EMF model but Instance A is an earlier version. Before using Edapt when Instance A and Instance B were the same version, the EMF XMIResource would create stub Instance B instances for the Instance A proxies and we used separate code to replace them with the correct in-memory instances. It seems that while Edapt deserializes Instance A it also creates stub instances of the Instance B content. However, the Edapt process fails the migration with those stubs. What's worse is that I have large numbers of these instances that all have to be loadable within a reasonable timeframe (<5 minutes) and the instances are typically extremely large.
The messages that it provides are pretty much all like:
The 'validType' constraint is violated on 'Reference "pointer" of Instance of type "[Instance A Container of Proxy Reference]"'
The 'validFeature' constraint is violated on 'Reference "[Instance A Container of Proxy Reference]" of Instance of type "[Instance B type of thing being referenced]"'
And the Edapt portion of the stack trace is:
at org.eclipse.emf.edapt.spi.migration.impl.ModelImpl.checkConformance(ModelImpl.java:508)
at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.checkConformance(MigrationReconstructor.java:174)
at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.checkConformanceIfMoreThan(MigrationReconstructor.java:167)
at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.loadRepository(MigrationReconstructor.java:190)
at org.eclipse.emf.edapt.internal.migration.execution.internal.MigrationReconstructor.endRelease(MigrationReconstructor.java:155)
at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.endRelease(CompositeReconstructorBase.java:179)
at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:81)
at org.eclipse.emf.edapt.history.reconstruction.ForwardReconstructorBase.doReconstruct(ForwardReconstructorBase.java:57)
at org.eclipse.emf.edapt.history.reconstruction.CompositeReconstructorBase.reconstruct(CompositeReconstructorBase.java:74)
at org.eclipse.emf.edapt.migration.execution.Migrator.migrate(Migrator.java:265)
at org.eclipse.emf.edapt.migration.execution.Migrator.migrateAndLoad(Migrator.java:217)
Is there a way to cause the Edapt proxies to attach correctly to the in-memory instance?
Barring that, is there any way to cause Edapt to NOT load proxies while uplifting a model? We could then use the same process to attach the correct in-memory instance by parsing out the proxy URI.
Barring that, is there a way that we could change the EMF model to a new version that could convert the proxy URIs into Strings (using any combination of volatile EReferences, new EAttributes, etc)? We could then use code similar to our old approach to attach to in-memory Instances?
I guess I'm looking for suggestions from anyone at this point.
|
|
|
Re: [Edapt] Proxy related issues on deserialization [message #1729390 is a reply to message #1729268] |
Wed, 13 April 2016 11:55  |
Eclipse User |
|
|
|
Hi Ian,
Pretty wild stuff.
There is currently no way to influence the loading code of Edapt like that.
If you want to take a look at the loading code and maybe play around a bit:
org.eclipse.emf.edapt.internal.common.ResourceUtils.loadResourceSet(List<URI>, List<EPackage>, IResourceSetFactory)
Otherwise performing a "pre-migration" without edapt could be an option.
So, you get the NS-URI from your XMI file. If this is the version which still contains those proxy references, you manually replace those with a new attribute + string and update the ns uri using some kind of XMI-tool.
When you create/adjust your Ecore to be able to load this model, you can start your edapt history with the actual model refactorings from this metamodel version.
|
|
|
Powered by
FUDForum. Page generated in 0.24462 seconds