Community
Participate
Working Groups
The aim of this bugzilla is to discuss whether it's appropiate to have root resource loaded out-of-the-box in a ResourceSet. Pros: - Stuctured ResourceSet - Consistency with the new Structured CDOResources - RootResource reachable by EcoreUtil.getEObject() & EcoreUtil.getURI(object). Cons: - Strange resource get's loaded without user permision, not desirable to client apps. Eike, Simon, could you comment on this?
I think for people that wants to have the same behavior as EMF it could be good to hide it. Victor, in your application is it bothering you to have another resource when using CDO ? I know you wanted to have the same behavior as straight EMF... We could have an option under CDOView.setRootResourceInResourcesetEnabled() :-) We will wait Eike to respond before doing anything!! Simon
Simon, I've found a situation where the root object produces great performance decrease. When removing an object in EMF Sample Ecore Editor, the following method is called to determine CrossReferences: EcoreUtil.UsageCrossReferencer.findAll(eObjects, domain.getResourceSet()); If the removed object is the Resource itself, it will perform a cross-reference check for ALL resources in the ResourceSet which, by having the root resource, will end up performing a cross reference check for the whole repository. This hangs up the editor for a while....
(In reply to comment #2) > Simon, > > I've found a situation where the root object produces great performance > decrease. > > When removing an object in EMF Sample Ecore Editor, the following method is > called to determine CrossReferences: > > EcoreUtil.UsageCrossReferencer.findAll(eObjects, domain.getResourceSet()); > > If the removed object is the Resource itself, it will perform a cross-reference > check for ALL resources in the ResourceSet which, by having the root resource, > will end up performing a cross reference check for the whole repository. This > hangs up the editor for a while.... > It could be a feature for some people... but not a good things for others!! :-)
(In reply to comment #3) > (In reply to comment #2) > > Simon, > > > > I've found a situation where the root object produces great performance > > decrease. > > > > When removing an object in EMF Sample Ecore Editor, the following method is > > called to determine CrossReferences: > > > > EcoreUtil.UsageCrossReferencer.findAll(eObjects, domain.getResourceSet()); > > > > If the removed object is the Resource itself, it will perform a cross-reference > > check for ALL resources in the ResourceSet which, by having the root resource, > > will end up performing a cross reference check for the whole repository. This > > hangs up the editor for a while.... > > > > It could be a feature for some people... but not a good things for others!! :-) > Well, ResourceSet is a "set of interrelated resources". By adding the root resource, you are considering ALL resources of the repository related somehow. I think that could be too excesive. At the end, all resources in a repository will always be related, and therefore, will alway be in every ResourceSet! This is just an example, but I think it could have major impact in many client applications.
ViK, I guess when you say "set of interrelated resources" you mean "a set of resources that must be interrelated". I'm not sure if I agree. How must they be interrelated? Pair-wise? I can not imagine that any spec forbids unrelated resources. On the other hand I'm also not sure if it's always "nice" to have the root resource in the resource set. Maybe we can make that optional and false by default? Simon, do you remember if there was an internal technical reason that *required* us to add the root resource?
Eike, (In reply to comment #5) > ViK, I guess when you say "set of interrelated resources" you mean "a set of > resources that must be interrelated". > I'm not sure if I agree. How must they be interrelated? Pair-wise? I can not > imagine that any spec forbids unrelated resources. Sure it doesn't forbid this. I just fit to ResourceSet definition: "A collection of related persistent documents" and also I recall a discussion we had regarding this issue, we you recommended me not to use a ResourceSet as a mere collection of unrelated resources, since it should be treat as a whole (I recall you saying "I would cut anyone's hand that dares to make a partial commit to CVS!"). Since structured repository was introduced there is, in fact, some sort of "relation" between all CDOResources. > On the other hand I'm also not sure if it's always "nice" to have the root > resource in the resource set. Maybe we can make that optional and false by > default? Simon, do you remember if there was an internal technical reason that > *required* us to add the root resource? I believe it's implicitly loaded into the ResourceSet due to the new structured CDOResourceFolder implementation.
(In reply to comment #5) > ViK, I guess when you say "set of interrelated resources" you mean "a set of > resources that must be interrelated". > I'm not sure if I agree. How must they be interrelated? Pair-wise? I can not > imagine that any spec forbids unrelated resources. > > On the other hand I'm also not sure if it's always "nice" to have the root > resource in the resource set. Maybe we can make that optional and false by > default? Simon, do you remember if there was an internal technical reason that > *required* us to add the root resource? > The reason is to have all objects reachable with rset.getEObject() Lets say we have the following structure: resourceSet |__RootResource | |_____ResourceA | |_____ResourceB | |_____ResourceFolder | |___ResourceC |__ResourceA |__ResourceB |__ResourceC RootResource, ResourceA, resourceB and ResourceFolder needs to have RootResource in the resourceset to be reachable from RootResource. ResourceC doesn't needs to. Simon
Eike, could you fix the bug name? (I don't know If I'm allowed to do that myself). I meant "Should root resource be optionally loaded in the ResourceSet?"
I will add an option in the view.
Rebasing all unresolved enhancement requests to 3.0
Rebasing all outstanding enhancements requests to version 4.0
Moving all open enhancement requests to 4.1
Duplicate *** This bug has been marked as a duplicate of bug 346636 ***
Closing.
