Bugzilla – Full Text Bug Listing
| Summary: | Support for determining incoming X-References efficiently | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Bernd Kolb <b.kolb> |
| Component: | cdo.core | Assignee: | Project Inbox <emf.cdo-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | saulius.tvarijonas, smcduff, stepper |
| Version: | 4.1 | Keywords: | helpwanted |
| Target Milestone: | --- | Flags: | stepper:
galileo+
|
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | Appealing to a Broader Community | ||
| Bug Depends on: | 256931 | ||
| Bug Blocks: | |||
|
Description
Bernd Kolb
Hi Bernd, You probably discussed this with Eike. Can Eike or yourself define a use case on how it should behave or the problem you encounter ? Thank you Simon Simon, There is EcoreUtil.CrossReferencer which collects all incoming references of a set of target objects. We'd like to have a round trip-based mechanism that provides an iterator over the set of cross-referencing objects for CDO. I could imagine an API like this:
public CloseableIterator<CDOObject> CDOView::queryCrossReferences(CDOObject... objects);
or this:
public class CDOCrossReferencer implements CloseableIterator<CDOObject>
{
...
}
There are two arguments for the latter form:
1) Since the operation can be expensive even for a particular back-end we don't encourage users to use it so easly.
2) I'm foreseeing similar mechanisms to be added for example for getAllInstances(CDOClass c), thereby polluting the CDOView interface.
Btw. a third option would be to only provide such queries through a generic query language (in the terms of the query framework). I'll write a respective comment to bug #256931 too.
Some thoughts on this: I find it specifically important to make the Feature a first class citizen in this query. Only rarely you need to know what is referencing an EObject in general rather than what is referencing an EObject in which context(feature) Additionally, I am not sure if such a feature should be mapped to the query language discussed in #256931 My feeling is that it should be handled as low-level as possible and thus executed/answered by backend directly API wise I'd be in favor for not mixing it with the CDOView. Just keep different things separate. Just my 2 cents Rebasing all unresolved enhancement requests to 3.0 Rebasing all outstanding enhancements requests to version 4.0 I think we solved this in bug 300149. *** This bug has been marked as a duplicate of bug 300149 *** Moving all open enhancement requests to 4.1 Closing. |