Community
Participate
Working Groups
The implementation of the above descriptor loads the complete CDO repo. Actually the implementation is the default implementation of ItemPropertyDescriptor which recursively follows all references of a given object. Via CDOResource -> folder -> CDOResourceFolder -> folder -> CDOResourceFolder it climbs up to the Root CDOResource and then descends into all CDOResources of the repository. This makes the use of Papyrus together with CDO very problematic for large scale repositories.
I suspect the same or a similar performance/memory problem may arise when loading large XML-formatted models from slow servers or file shares. I wonder if there's a reasonably smaller scope (than a complete resource set), which would still reach all model elements. I.e. is it reasonable to assume that a model (di, uml, notation, and maybe a few others) represents a complete scope for reference endpoints?
Did you mean to file this bug in the UML2 project? The item providers in question are supplied by EMF and/or UML2.
I have thought this over a little bit. This is not a specific UML problem. It is caused by a CDO feature namely: CDOResourceNode.folder. It will happen with any model that makes use of the standard way to resolve these choice values. It's just Papyrus with CDO which just popped up the issue. So the question is: can this issue be solved in general? And if so where would that be? For sure it makes the use of standard EMF ItemPropertyDescriptor critical for any use of CDO.
