[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Removing MatchQuery in M7.

Incidentally, The QL language actually has select, collect, etc. implemented in a way that is very smalltalk'ish.

Please declare this topic done. I'll get over it :-)

- thomas


On 03/31/2010 10:59 PM, Jeff McAffer wrote:

woohoo!! Smalltalk!  He said Smalltalk!  You are my hero for the day.

Seriously, there appear to be several people with serious reservations so I don't see how the type can be removed for 3.6.  Can we declare this topic done?

Jeff


On 2010-03-31, at 2:47 PM, John Arthorne wrote:

I suspect from bug 304130 my opinion on this is already known, but just to be clear I'm still very much against removing MatchQuery. I think _expression_ queries are very useful for a limited set of use cases, and the built in _expression_ queries provided by QueryUtil that exploit repository indexes are great. However, I think an alternative to _expression_ queries needs to exist for clients who want to write custom queries and have nothing to gain from using _expression_ queries and don't want to live with their added complexity. When I originally created the query API I intended it as a very general purpose mechanism much like the Smalltalk select: statement (in hindsight maybe I should have called it that and we wouldn't be having this debate), and I think it would be a mistake to constrain our API to only allow _expression_-based queries.

John

On Wed, Mar 31, 2010 at 11:19 AM, Thomas Hallgren <thomas@xxxxxxx> wrote:
As stated in the deprecation note for MatchQuery, we would like to get rid of this class for M7. We are also very anxious not to disrupt our clients.

Risks:

Clients may depend on the deprecated class. An alternative solution is included in the deprecation note but some code still need to be moved.

Benefits:

1. Tests show that performance is at least a 100 times better when indexes are used. A MatchQuery can never use an index.
2. We don't risk queries that have side-effects during evaluation.
3. The _expression_ evaluator can be cleaner if concerns about MatchQuery are removed.
4. API is cleaner and easier to elaborate.
5. Queries can be executed by a service in another process (database, remote, etc.)
6. No need to expose API for, or document, internal query behavior.

Regards,
Thomas Hallgren

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev