Community
Participate
Working Groups
There are many situations when you would like to do a query without necesarilly adding its result to a Collector. Perhaps you already have a collection of some sort that you'd like to use, or perhaps you simply want to pass the matching objects to something else (a pipe) for further processing. The Collector is an fairly special implementation that uses an HashSet as its collection. It is possible to override but when doing so, all methods that uses the private collected field must be overridden. That includes: getCollection() isEmpty() iterator() size() toArray() toCollection() It would be better if the Collector was an abstract class and all accesses to the collected field was made through an abstract getter method. A specialization, perhaps named HashSetCollector could then implement the current behavior.
Thomas, One of the goals of the Query Management was to remove the passing in of the collector. You can simply "query" a queryable. If you want to combine results, etc.. you do that when the items return. We actually made very good progress last year on this, and I decided to revisit this work. It turns out we can almost refactor the queryable to remove the passing in of the collector, and I'm going to try and push on this for the API branch. Instead of passing in the queryable I was thinking of something like this: IQueryable#query(IQuery query, int numberOfResults, boolean suppressDuplicates) If you pass IQueryable.ALL as the results, then you get them all. All the custom collectors are either used to short circuit the query or change how duplicates are handled. Now by doing this, we gain greater flexibility on how custom repos choose to handle queries. They can now interpret the query and and choose to transform it to SQL or something that makes sense to their internal storage.
That makes a lot of sense. If implemented that way, this bug can be closed.
I'm honestly not very keen on the suggested form of the query method in comment #2. It does resolve today's problems by does not really give much ways in extending in the future. I think we will need to discuss that again.
(In reply to comment #3) > I'm honestly not very keen on the suggested form of the query method in comment > #2. > It does resolve today's problems by does not really give much ways in extending > in the future. I think we will need to discuss that again. Thanks Pascal, I agree we should discuss this. See Bug 256355#25 for some more thoughts. Let's add this to the agenda for the next p2 meeting.
Where do we stand on this issue?
I reported this but as far as I'm concerned this can be closed now since we a) no longer require the Collector for a query and b) have an IQueryResult interface.
marking as fixed.
Nothing was actually "fixed" here, it's just not needed anymore.
