[KinoSearch] more abstract interfaces to kinosearch

[Hans Dieter Pearcey]

On Wed, Jun 20, 2007 at 09:05:58PM -0700, Marvin Humphrey wrote:
> >* easier searching, without using QueryParser, like SQL::Abstract  
> >(since
> >  that's what I'm used to):
> >  $hits = $index->search({ foo => 1, bar => [ (qw(baz quux) ] })
> 
> Sounds like a good idea for an extension.  Constructing large queries  
> via the KinoSearch::Search::Query subclass constructors can be  
> tedious.  At the same time, I wouldn't want to have to implement/ 
> document those constructs in Searcher itself.

Now that I've worked on this for a little bit, I have some best
practices/performance questions.

Take the example query that I gave above:

  { foo => 1, bar => [qw(baz quux)] }

Let's say this translates to the SQL
  
  WHERE foo = 1 AND (bar = 'baz' OR bar = 'quux')

I can't find any way to do the OR, there, in a Query, only with PolyFilter.  In
this particular case that isn't a big problem, since there's still the
TermQuery for 'foo = 1', but it's easy to imagine a query that translates
entirely into Filters and has no Query.  What do I feed the searcher then?

Given the existence of QueryFilter, is there any documentation on what you
would want to use as a query and what you would want to use as a filter via
QueryFilter?  I looked through the source, but it was on a plane back from YAPC
and I was tired, so I may have missed clues.  I suspect it's something like
"filters should be reused because they cache stuff, while queries can be
one-off because they don't", but I'm not sure.

If that's all there is, is there any roadblock to a Query analogue to
PolyFilter (PolyQuery)?  Is there something about OR that makes it difficult to
do there?  Likewise, is there anything about the RangeFilter that would make it
difficult to turn into a query?  For my application, I have both OR logic and
ranges that I expect to change with some frequency.

hdp.