Community
Participate
Working Groups
Currently the root resource is added to the resource set. This can lead to various problems e.g. if there are self adapting adapters attached to the resource set like EContentAdapters, CrossreferenceAdapters or TransactionChangeListeners. Hence it would be better to not attach the root resource to the resource set.
We consider the fact acceptable that resource.getEObject(URI.createURI("cdo://repo1/#L1")) can no longer deliver the root resource instance through EMF API.
Oh, this topic sounds familiar to me :P 251467: Load the root resource only optionally into the ResourceSet https://bugs.eclipse.org/bugs/show_bug.cgi?id=251467 We solved it in a different way: Use LazyContentAdapters and LazyCrossReferenceAdapters. Only adapt elements that are actually loaded.
Hi Vik, thanks for pointing us to this bugzilla. It is indeed quite related to this one. Eike and I worked for several hours on Bug 345858 and finally came to the conclusion that it is best to remove the root resource completely from the resource set. Using the LazyAdapter is a good idea, but I think this solution will also work in cases where the user cannot change the implementation of the self adapting adapter. ;)
Created attachment 196218 [details] Patch v1 Attached a patch which removes the root resource from the resource set and changed all related tests.
*** Bug 345858 has been marked as a duplicate of this bug. ***
Martin, > thanks for pointing us to this bugzilla. It is indeed quite related to this > one. Eike and I worked for several hours on Bug 345858 and finally came to the > conclusion that it is best to remove the root resource completely from the > resource set. Using the LazyAdapter is a good idea, but I think this solution > will also work in cases where the user cannot change the implementation of the > self adapting adapter. ;) thats right, the responsible is indeed the root resource, and this may be seen as a *workaround*. However, the root problem is still there: GMF uses content adapters which forces to load the whole model, which invalidates many of the main features of CDO. This also removes the possibility to deal huge models: it may be the case that the diagram requires to load a model as big as your java heap. I understand that the implementation cannot be changed. I thought Dawn used fragments to override GMF Code. In our case we overrode TransactionalEditingDomain to use these adapters. We are now able to load HUGE diagrams. Diagrams that are so big that it make no sense to visualize them :P Without the lazy adapters, loading those models was simply impossible. In any case, the root resource modification is something really interesting that I requested long time ago, but could not find a solution for it. I though it would require deep changes in the framework. I will be welcome!
(In reply to comment #6) > thats right, the responsible is indeed the root resource, and this may be seen > as a *workaround*. However, the root problem is still there: GMF uses content > adapters which forces to load the whole model, which invalidates many of the > main features of CDO. This also removes the possibility to deal huge models: it > may be the case that the diagram requires to load a model as big as your java > heap. > > I understand that the implementation cannot be changed. I thought Dawn used > fragments to override GMF Code. It does. ;) This patch should also help other uses/frameworks beside GMF to work with SelfAdapters if they cannot change these. > In our case we overrode > TransactionalEditingDomain to use these adapters. That is similar to what I do. But I have to admit that currently I did not implement anything to handle huge models. But this must be done soon. I think your LazyAdapters will be a perfect solution for it. :)
Committed revision 7825
Available in R20110608-1407
*** Bug 251467 has been marked as a duplicate of this bug. ***
