Community
Participate
Working Groups
With Ian's query work we ended up with two very similar classes: CompositeQuery and CompoundQuery. From looking at their API I can't really see the difference between them, or why I would choose one over the other (except CompoundQuery supports both AND and OR, and CompositeQuery only does AND). The new CompositeQuery is only used in two places, and most of our code still uses the old CompoundQuery. Why do we need two? Can we get rid of one and consolidate on the other?
I had noticed a difference particularly when using non-IMatchQuery's CompoundQuery basicaly ran both queries on the full data set and then AND'd or OR'd the results together. CompositeQuery ran the first query on the full data, then ran the second on the results of the first. The difference being something like O(n^2) vs O(log(n)) (I think)
A CompoundQuery runs each query, and you can choose to AND or OR the results. There are some performance tricks if you have match queries, because we can do this work in parallel. Composite queries runs the first query and uses the results of that as input into the second query. For example, give me all the EMF features, now give me the 3 most recent features. This would give you the three most recent EMF features. This type of query cannot be performed using a CompuondQuery.
So to answer the question, why two queries? They do separate things. Some of the discussion (and examples) were discussed in Bug 260012.
After re-reading the comments in bug 260012 I completely understand the different uses again. However I and others keep hitting this, and I think the problem is that the query class names aren't expressive enough. I can't tell any meaningful difference between CompoundQuery and CompositeQuery from the class names, so each time I use one I have to look closely at the distinctions again. maybe CompositeQuery should be called something like PipedQuery to make the distinction clearer?
(In reply to comment #4) > After re-reading the comments in bug 260012 I completely understand the > different uses again. However I and others keep hitting this, and I think the > problem is that the query class names aren't expressive enough. I can't tell > any meaningful difference between CompoundQuery and CompositeQuery from the > class names, so each time I use one I have to look closely at the distinctions > again. maybe CompositeQuery should be called something like PipedQuery to make > the distinction clearer? > +1. I agree, the names are not great (I spent a lot of time in these classes, and I have to look at the code to remember which one is which). I like PipedQuery.
Created attachment 127933 [details] Rename composite query to piped query I thought that PDE Build used composite query, but I don't see that now. This patch renames composite query, and changes the references I could find in the SDK. (Only seems to affect p2).
Created attachment 127934 [details] mylyn/context/zip
Is this something we want for 3.5, or should we do this early in 3.6 (in time for API review)? I'll mark this 4.0 so we don't loose it.
Not for 3.5.
Created attachment 149664 [details] Updated patch Since the query stuff moved, the old patch became stale. This updates the patch.
I have released this fix to the API Cleanup Branch. There does not appear to be any clients outside p2 in the SDK.
