Community
Participate
Working Groups
In theory, Papyrus models of any size can be stored in a CDO repository in their entirety in a single resource because of CDO's innate scalability. However, this is severely limited for UML by two factors (primarily): * the UML metamodel is a CDO "legacy" model, which as such does not support lazy loading of collections and other references * the UML metamodel implementation self-attaches the CacheAdapter, which loads the entire contents of the contextual Resource Thus, it is necessary to support in CDO persistence the same "controlled resources" facility, with attendant lazy-loading hooks in the ModelSet, as is employed in Papyrus's workspace resources to support model scalability.
Hi Christian, Is it feasible to modify UML project rather than CDO?
(In reply to comment #1) > Hi Christian, > > Is it feasible to modify UML project rather than CDO? I don't foresee a need to modify either CDO or UML: the lazy-loading and controlled resources scheme is implemented in Papyrus (in its model-set and related APIs) and that is where this enhancement will be implemented.
I see. My comment was more about the possibility of regenerating the UML framework for native CDO (and if needed provide it in parallel with the EMF-based code for compatibility purpose) and modifying the CacheAdapter behavior. But I guess it would require to adapt/refactor a lot of manual code in UML.
(In reply to comment #3) > > But I guess it would require to adapt/refactor a lot of manual code in UML. Ah, I understand. Yes, this was considered for Kepler and rejected for that and other practical reasons. However, (I shall do my best to ensure that) there is nothing precluding such an effort in the future.
Fixed in master: commit 8d4fc1035f951a55263c89748dc9bcec6b761042 through commit 0777ed71475833b262df3d052832060620a3bdc3 including new automated tests to cover a few basic scenarios. References across controlled-unit boundaries employ a CDO-style proxy that is lazily loaded in the usual way, subject to the policy hook in the OnDemandLoadingModelSet (which the CDOAwareModelSet specializes). Because CDO normally only uses proxies for references to objects persisted outside of the repository, this implies: * injecting proxies for references from a resource in one model unit to a resource in another model unit. Note that references between resources in the same unit, e.g. notation -> uml, are not proxies * when saving a model (i.e., committing the CDO transaction), processing all new and changed objects to ensure that any new or changed cross-unit references are correctly implemented as proxies This effort required some refactoring of the core Papyrus frameworks for lazy-loading/control-mode and the ModelSet: * lazy loading assumed that "user models" are in the workspace, and so specifically looked for platform:/resource scheme URIs. This does not work for CDO models because their URIs use a cdo: scheme. So, the ModelSet now has API to query whether a URI identifies a "user model" resource (commit 8d4fc1035f951a55263c89748dc9bcec6b761042) * the dialog for selection of the resource to create for a new controlled unit allows the user to browse the workspace or local filesystem. This does not work for CDO models in which the browse scope should be the model repository. This dialog is now factored out into a pluggable provider interface (commit 2e7846061682c6029fad8f0ad296a1e37d136fd5) * the ModelSet's delayed deletion of resources when saving after an uncontrol operation depended on resources being stored in workspace files. This is now refactored for extensibility to support different persistence stores (commit ee019cc6f47126d1a08e2c4b21d047c64fa068c1)
