[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Query Management Proposal
|
Hi, Ian. I was thinking the same thing (that trying to phase this in incrementally is bigger than the technical challenge)...!
I think that somewhere during #2 and #3, I should revisit the QueriedElement code in the UI and start wrapping the iterated IU's with element objects from there, rather than in the collectors. That should simplify the collector stuff extensively. Ping me when you get there (I'll try to make a point to hang out on equinox-dev)...
susan
![Inactive hide details for "Ian Bull" <irbull@xxxxxxxxxxxxxxxxx>]()
"Ian Bull" <irbull@xxxxxxxxxxxxxxxxx>
![]()
| ![]()
| ![]()
To: "P2 developer discussions" <p2-dev@xxxxxxxxxxx>
cc:
Subject: [p2-dev] Query Management Proposal |
I have updated the query management proposal by adding bug numbers and a better description of the problem [1] (Query and Query Results are too tightly coupled). When complete, this will allow anyone implementing IQueryable to:
1. Build custom query mechanisms
2. Return results in different ways (lazy / incremental for example)
This is not just for those building DB backed repositories, as I could imagine even the default p2 repos taking advantage of these things (for example, we could store the IUs ordered by version number, then create a custom query for getLatestIU that uses this fact).
While the proposal has a lot in it, what has been more daunting for me is how I can do this in a manageable way. Nobody (especially not me) wants a single patch that tries to cover everything. To address this proposal, I propose tackling the issues as follows:
1. Design support for Compsite Queries: This includes both making Collectors queryable [2] and support "CompoundQueries" [3]
2. Rewrite complex collectors as queries. I have started on this with LatestIUVersionElementQuery [4]. I will work towards other as the week goes on.
3. Once the complex collectors have been removed, we can eliminate the need for the collector to be passed to the query [5]
4. Also, once the complex collectors have been written in terms of Queries, we can identify Queries which are "Transparent". These queries will have "known" semantics and access to their fields so others can provide custom implementations [6].
5. Finally, we can re-design the Collector interface to support incremental loading of results, status, etc... Since clients will be free to implement their own Collector (See point 3), this will likely be an exercise in design more than anything else. I will likely need a hand here (hopefully from Jeff, Scott, Susan, Tomas and Hendrik). (Of course, everyone else is also welcome :) )
[1] http://wiki.eclipse.org/Equinox/p2/Proposals/Query_Management_and_Optimization
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=260112
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=260012
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=260105
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=256355
[6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=256412
Cheers,
Ian
--
R. Ian Bull, PhD
Software Developer, EclipseSource
http://www.ianbull.com
http://blog.ianbull.com_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
