Community
Participate
Working Groups
The following problem showed up while preparing a tutorial on the OCL delegate functionality, but is not really an OCL problem. While using the Sample Reflective Ecore Editor to edit a dynamic XMI model, the Ecore meta-model was changed to enhance a validation constraint. Invoking Validate then gives an NPE in OCLDelegateDomain because the EPackage has no eResource; the EClass is a proxy. When the meta-model is changed, EcoreEditor.handleChangedResources (in response to handleActivate) invokes eSetProxyURI to trash the meta-model, but the model instance continues to use those proxies as its meta-model. This was not previously a serious problem because the proxy meta-model did not cause obvious problems, although it perhaps contributed to my wariness of two Ecore Editors with a ResourceSet overlap. The scenario of a changing meta-model is important to OCL users who may be developing their OCL constraints and exercising them on the loaded model. Is there an easy way for EcoreEditor.handleChangesResources or ValidateAction to fix up the proxies? My quick experiments with EcoreUtil.resolveAll suggest that the underlying EcoreUtil.resolveCrossReferences was not intended to resolve dynamic meta-model proxies.
No, editing a model for which instances exist isn't supported. The model could change arbitrarily in ways that invalidate the instance.
Yes, clearly for an arbitrary meta-model change the model cannot survive. But 1: there is a significant use case in which the meta-model change is compatible where it is unkind to require the user to close and re-open the editor. It would be nice, perhaps to offer a do you want to reload prompter, that may then fail dreadfully during reload just as an independent reload would fail. But 2: the Sample Reflective Ecore Editor continues after a meta-model change having reloaded the meta-model. A wide variety of nasty NPEs, CCEs, IAEs, happen to the ongoing usage, many of them are in the OCL validation, but some are in EMF alone. If reloading the meta-model was invalid, it should not have been reloaded.
Things like EObject.eClass() would need to resolve EClass proxies, but I don't want to add such code for all clients. The new EClass could be totally different, so any type of failure is possible anyway. I don't see a good way to make this robust, nor do I have the time. Contributions that don't impact the core runtime would be interesting to see.
Agree; it definitely should impact core run-time. I'm thinking in terms of a refreshMetaModel facility that could be invoked from EcoreEditor.handleChangedResources. It would a) resolve all eClass proxies b) diagnose incompatibilities with the features and perhaps one day c) offer an opportunity to delete/rename offending elements
