Quote:
Originally Posted by curt.clifton
I guess one could retrieve the list, filter it, then process it
|
If one wants to make use of
where queries, (to improve performance, for example) retrieval and filtering have to be combined.
(The
where clause is part of
get syntax, and can't be applied to lists - hence the scope for an efficient implementation).
Quote:
Originally Posted by curt.clifton
Do you see an easy way to use the where-queries and still factor out the filtering into a separate handler?
|
You might find a meta-programming route to passing variable arguments to
where clauses. (I can't spot a simple one at the moment -
run script gets messy if you try to circumvent its overheads - See Matt Neuburg's section on the Run Handler).
Short of this, and given the need to combine filtering with retrieval, the main room for flexibility probably lies in branching, at some level, between multiple retrieval options, each with an alternative hand-coded
where clause.
A trade-off, as always, between flexibility and performance, but a useful rule of thumb is to exercise parsimony and discretion wherever possible in the implicit or explicit use of
get, by adding a
where condition or two - it can make code simpler, as well as faster.
--