Community
Participate
Working Groups
It would be great to extend CDO with the possibility to query all the objects referencing a certain object. The so-called crossreferencing (or xref) functionality. Using the model available on the server it is possible to determine for each EClass what queries are needed to retrieve the referencing objects. A thing to consider is how to handle larger volumes of referencing objects. It is clearly possible that multiple queries are needed to retrieve all cross referencers so it can be difficult to implement paging or sublist behavior. So maybe the client api can pass in a max number of returned objects. To support xref I think we need: - an api and convenience method on the client - a server side api definition - implementation of this functionality in each store Eike and others let me know if you have any comments or feedback on this. Thanks! Martin T.
For your info, this feature was present in CDO 0.7: https://bugs.eclipse.org/bugs/show_bug.cgi?id=155725
Created attachment 162388 [details] Utility class retrieving cross referencers by CDOQuery I thought I could share this class as an initial suggestion to solve resolving cross references in the database. I use it in my application and it works well. Callers of the method getDbCrossReferencers will also have to consider local changes in the view. The EPackages can be registered at initiation (when they anyway are registered)
Created attachment 166221 [details] patch v1 Hi, this is result of a dicussion between Eike and I. This query language is DBStore dependant.
I'm gonna make also a DBStore test for this new query language
Created attachment 166359 [details] patch v2 - Added API Support in CDOUtil: CDOUtil.getCrossReferences. This returns a nice Setting implementation with Lazy behaviour, this is, referencer EObject is not retrieved eagerly when instantiated, rather when calling any of the methods in the Setting API. This method depends in the backend supporting XREF language. - The EStructuralFeature through which the object is referenced can be retrieved. This has been made configurable now, by passing a boolean "provideFeatureName" parameter. - It is no longer necessary to specify the CrossReferenced object's EClass and EPackage nsUri. These are extracted from the backend - Multiple bugs fixed
Now that I look at the Martin's initial comment, I must warn that: - the path provides only functionality for DBStore (however, this can be implemented the same way for other IStore by using the CDOQuery API) - nothing implemented regarding sublist and paging, but CDOQuery API itself provides iterator mechanisms. But I tackled: - an api and convenience method on the client (CDOUtil.getCrossReferences())
Comments: 1) CDOIDUtil.getLong(object.cdoID())) is only good when you exactly know that the id is a CDOIDLong, but you can not know that in the client. Put the whole object into a query parameter instead. 2) If the query has a parameter (XREFQueryHandler.provideFeatureName) why is it not usable in CDOUtil? 3) XREFQueryHandler.provideFeatureName must not be an instance field. 4) BLOCKER: Your XREFQueryHandler assumes a certain DB schema that only the mapping strategy can know.
Created attachment 167618 [details] patch v3 (little bit reformatted)
(In reply to comment #7) > Comments: > > 1) CDOIDUtil.getLong(object.cdoID())) is only good when you exactly know that > the id is a CDOIDLong, but you can not know that in the client. Put the whole > object into a query parameter instead. agree > 2) If the query has a parameter (XREFQueryHandler.provideFeatureName) why is it > not usable in CDOUtil? The new method in CDOUtil returns Collection<EStructuralFeature.Setting>. To construct these, "provideFeatureName" must mandatorily be true. Making it configurable in that method is incompatible with the return value. > 3) XREFQueryHandler.provideFeatureName must not be an instance field. agree > 4) BLOCKER: Your XREFQueryHandler assumes a certain DB schema that only the > mapping strategy can know. I guess you refer to the SQL queries constructed in the xrefXYZ methods. Could give me a hint on how to get that information from the mapping strategy?
(In reply to comment #9) > > 4) BLOCKER: Your XREFQueryHandler assumes a certain DB schema that only the > > mapping strategy can know. > > I guess you refer to the SQL queries constructed in the xrefXYZ methods. Could > give me a hint on how to get that information from the mapping strategy? You need to add new methods to IMappingStrategy like queryCrossReferences(...).
> You need to add new methods to IMappingStrategy like queryCrossReferences(...). are we going to add a new method to IMappingStrategy each time we create a new query? :(
Created attachment 167895 [details] patch v1 includes all suggested changes except last issue
Created attachment 167896 [details] patch v4 oops, wrongly versioned
Rebasing all outstanding enhancements requests to version 4.0
Created attachment 173420 [details] Patch v5
Committed to HEAD. But waiting for bug 318998 [DB]...
*** Bug 256927 has been marked as a duplicate of this bug. ***
Available in R20110608-1407
