Community
Participate
Working Groups
MDT/OCL 3.0.0 has no support for Ecore opposite ends so incurs no associated costs. Introduction of the DefaultOppositeEndFinder may impose significant costs on existing users since the entire EPackage.Registry is analyzed for potential opposites and partially reviewed for every opposite resolution. The default EPackage.Registry is surprisingly large once a few modeling projects are loaded, so this is an undesirable cost. Unless we can be clever, the default behaviour should therefore set the oppositeEndFinder to null to minimise impact. However how can the new functionality be used if the default is null? The problem is the analysis of _all_ packages. Surely it is sufficient to analyze the transitive closure of all packages referenced by the models populating the extent? This will be a much more manageable cost that won't grow as additional projects are installed. If the DefaultOppositeEndFinder is configured for the relevant subset of the EPackage.Registry the Bug 333082 per registry cache rationale is invalid. With a known relevant subset of packages, the DefaultOppositeEndFinder could listen for changes and so only incur the updateOppositeCache() cost when necessary, or more likely require the packages to be immutable and so never invoke updateOppositeCache(). Configuring the DefaultOppositeEndFinder according to the meta-models for the extent seems to be a good solution. I think we end up with two modes of operation: If users use one of a variety of (deprecated) default constructors then the global EPackage.Registry and a null OppositeEndFinder result. This gives no functionality change and no opposite support. If users explicitly provide a (possibly DelegatingPackageRegistry) set of packages in constructor arguments, or activate OCL support in the context of an EObject (the OCL Console) or an extent of EObjects, then the DefaultOppositeEndFinder analyzes the closure of the eClass() and the new opposite support is available automatically. The cost of full global EPackage.Registry will only occur if a user explicitly specifies it.
In the same way that we recognised that Map is an inappropriate type for Extent configuration, I think EPackage.Registry is inappropriate for meta-extent configuration. If we reverse the construction order and have a MetaExtent that implements EPackage.Registry and OppositeEndFinder, we can pass this to the existing Environment etc constructors, but automatically share the OppositeEndFinder caches for shared EPackage.Registry content. The MetaExtent is responsible for all things to do with a particular selection of user meta-models and is shareable across Environments. [Open to suggestions for a better spelling of MetaExtent.]
(In reply to comment #0) > Introduction of the DefaultOppositeEndFinder may impose significant costs on > existing users since the entire EPackage.Registry is analyzed for potential > opposites and partially reviewed for every opposite resolution. The default > EPackage.Registry is surprisingly large once a few modeling projects are > loaded, so this is an undesirable cost. Can you quantify and thus substantiate your assumption before we spend significant effort on something that turns out to be insignificant after all? For example, an impact would only exist during parsing/analyzing. Would it exist only for properties not otherwise resolvable when the analyzer resorts to looking for a hidden opposite? How frequently does that happen? Etc.
Eclipse as a whole goes to considerable lengths to ensure that unused plugins are not loaded. The plugin registration of delegates ensures that the packages available from plugins are known even though the plugins remain unloaded. This is critical to the scalability of Eclipse. Therefore anything that actively scans the entire global EPackage.Registry automatically loads all modeling plugins and, as from E4, increasing numbers of non-modeling plugins. I overlooked this aspect when reviewing. Since this affects fundamental scalability I'm raising the priority to Critical. If we cannot fix this for M5, we should disable the DefaultOppositeEndFinder to avoid impact on existing users. OCL must not load/start plugins that are not needed. In terms of quantification, I can only offer the unuseability of the Galileo Modeling Platform for which large numbers of incubation projects interacted very badly. It was close to unuseable (by me) because of the slow global behind the scenes activities. (In reply to comment #1) > [Open to suggestions for a better spelling of MetaExtent.] My favourite 'new' supervising classnames are: MetaModelManager providing all user meta-model functionality for use with an Environment during parsing and analysis. ModelManager providing additional model caches for use with an EvaluationEnvironment during evaluation.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=333082 and patch https://bugs.eclipse.org/bugs/attachment.cgi?id=185931 which also fixes this problem (no implicit package bundle loading).
Fixed together with https://bugs.eclipse.org/bugs/show_bug.cgi?id=333082
http://wiki.eclipse.org/MDT/OCL/New_and_Noteworthy/Indigo needs updating to at least identify the Bugzillas. The Impact analyser and opposites are more than casual manitenance and so deserve at least a couple of paragraphs of description - perhaps referring to more extensive descriptions in a more persistent location.
Closing
