[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] iterators, queries, and collectors....oh my!!



Susan Franklin McCourt wrote:

Hi, Ian...

>1. Queries that cannot be done asynchronously (because of their implementation). For example, if a query needs all the results to make decisions, (get the IU with the greatest version).

I think this is where Thomas was asking for a finite set of non-opaque queries.

My cut on that situation was that with well-defined queries, a IQueryable implementor could check if the query was of a particular type and then reform the query by interogating it for the values (e.g., pattern, version ranges, ...) and then invoke some sort of optimized form with the same semantics.  Your example of the LatestIUVersionQuery could actually be implemented on a suitable database repo such that it did not have to look at everything.  Similarly, we could change the standard p2 repos to keep the latest in a special way such that such a query could be answered in constant time.

Another lifecycle thing to consider is how/when results are available. For LatestIUVersionQuery, any implementation couldn't possibly know the results until it had looked at everything. For PatternMatchQuery, the results are cumulative and it would be nice if some results could be made available incrementally so that the UI could show a subset of results faster. For example, I wouldn't want to make the user wait until every IU with "*rel" were found before showing anything (as we do today). And I wouldn't want to block on hasNext() if the queryable was still working, I'd want a way to know if the repo is still working on the next one, or is truly finished. For that reason, I'm not sure if Iterator is enough. In the UI I imagine a pattern where a job would periodically fetch the results and populate the view, and keep rescheduling the job until the collector was really done. Something like

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.

One more thing - the nasty "uncategorized" query might be made to go away by us mandating that only categorized things are shown by the UI when working in category mode (vs. assembling the uncategorized info). That's probably the best way to make that problem go away rather than making it work in a query. (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=227675#c16).

Is that a near term solution just for our UI or can we apply the same logic to the general class of query?

Jeff