Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] iterators, queries, and collectors....oh my!!
Ian Bull wrote:


This is a great usecase.  In the IFutureStatus proposal there is hasNext() and isDone().  Does this capture the situation from an API point of view? (i.e., is mightHaveNext() equivalent to !isDone())?  I don't think the current FutureStatus impl has the desired semantics for this case but clearly something could be implemented.
Regarding filtering, does anyone have thoughts on the following scenario:

Say I have a query that looks for IUs that are SDKs (they have SDK in their name or something), and I invoke this query. (it may go across the wire, it doesn't really matter).  As this starts returning results, I start to populate a list.

Then I filter the list (looking for the EMF SDK I type EM).  Does it make sense for this to be a new query (look for SDK's + name contains "EM"), or should we have a "filter" on the query results.  So I can say, ok, as these results come in, only give me back ones that contain EM. Then, if I type EMF, it has all the results, and it just does a different filter.

So essentially, should we have "pattern match" or simply "filters" on query results?

I think there are two scenarios:
1. I know what I want before the query is issued. In this case its beneficial to do the filtering on the server side. Include the filter in the query so that it is possible for the query implementer to transform the filter and include it in a database query.
2. You discover, as you look at the results in a UI, that you should have added a filter. In that case it will be beneficial if the UI has some filtering capabilities that can be applied on the query result. This is similar to client side sorting, i.e. you click on a column to get the result sorted ascending/descending by that column. Issuing a new query just to get a new sort order would probably be slow.

In essence I think it all boils down to that the more descriptive the query can be, the better. Simple filtering on properties and such can easily be translated into SQL expressions in a database query and the database will often do a far better job then just applying such filters sequentially on everything that it finds.

Regards,
Thomas Hallgren

Back to the top