| Re: [p2-dev] iterators, queries, and collectors....oh my!! |
Jeff McAffer wrote:
I agree. A Version can be implemented as a UDT (User Defined Type) in a database with sufficient semantics to enable both comparison and efficient indexing. That in turn will allow for efficient queries for things like "latest version" etc.Susan Franklin McCourt wrote: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.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.
I'm a bit puzzled by this discussion about asynchronous queries that will deliver incomplete results and then continue. To me this sounds like a problem that should be limited to the user interface domain. Only a human looking at a screen will benefit from the incomplete results. Any logic that would potentially stop after receiving partial data should instead describe this with a result size limit or some semantics expressed in the query.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.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
If this is for UI purposes only, then surely an iterator is enough. A separate job is needed to perform the iteration and deliver the results (this job will hang on hasNext()) but I fail to see why the behavior should be propagated all the way to the query evaluator and change its API.
Regards, Thomas Hallgren