Community
Participate
Working Groups
Created attachment 171848 [details] CompoundQueryTest I've run into a couple bugs in the implementation of compound queries. Essentially in an AND query our evaluation will only consider the class of the first query, while an OR query will match any class as it compares to Object. I've attached a patch for a test class which should hopefully make my explanation clearer.
A compound query that is compiled from queries that expect instances of different classes will not work very well. What's the use-case where you see this as a problem?
When I ran into the problem I was writing a query to find IProfile and URIs (which represent metadata repositories) as part of a QueriedElement. The test cases are just simplified examples to demonstrate the problem.
Is QueriedElement an IQueryable<T>? If so, what's its type? Mixing URIs and IProfiles seems a bit odd to me.
The QueriedElement has a queryable field and the children are found by a QueryProvider by running a query on the queryable.. The combination or IProfile & URI seems strange but the MetadataRepositoryElement uses a URI rather than a IMetadataRepository.
Perhaps what you're after is covered by the public IQueryable<URI> locationsQueriable() on the QueryableRepositoryManager ?
The problem is that the way the QueryProvider & QueriedElement are written there is one queryable, and one query. In this case I was creating a ProvView which had profiles & metadata repositories as top-level elements in the tree. To do this I had created a CompoundQueryable which combined the sources for profiles & metadata repos but querying turned out to be impossible with a CompoundQuery. I believe I solved my problem by using different top level elements, the bug is just intended to point out the problem with the CompoundQuery.
(In reply to comment #6) > I believe I solved my problem by using different top level elements, the bug is > just intended to point out the problem with the CompoundQuery. I agree that there is a problem. I think the solution is to refrain from optimizing a ComponentQuery where the included queries are of different types. Context queries will need to execute separately and then be merged (intersect or union). Match queries will be merged on an expression level but the expression will need to contain type checks.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
