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
|
