[KinoSearch] Using no analyzer with trunk

[Marvin Humphrey]

On Sat, Apr 11, 2009 at 09:09:31PM -0500, Peter Karman wrote:

> regardless, you'll probably want to catch basic poor query syntax prior to
> handing it to KS anyway.

This is a good idea for many query parser implementations, and may be
necessary with FlatQueryParser, since it's based on Parse::RecDescent.
However, the standard KinoSearch QueryParser's parse() routine is designed to
be extremely tolerant of malformed input, to the point of being bulletproof --
it shouldn't ever throw parse exceptions.  The segfaulting needs to stop, but
once that's addressed, there won't be any exceptions to catch.

> Marvin, I don't know if you have such a feature already, but something like
> MySQL's EXPLAIN [0] feature might be a nice idea down the road. It wouldn't
> address this particular problem, but it got me thinking about understanding how
> the QP works.

I agree that a good explain() function would be very useful.  However, it's
not high on my priority list.

Nevertheless, I recently finished implementing a "dump()" method in all Query
subclasses, which spits out a JSON-izable data structure that can be used to
feed Data::Dumper.  dump() is also implemented for Schema, all FieldSpecs, and
all Analyzers.  It comes in handy now that all KinoSearch objects are opaque
blessed scalars.

Marvin Humphrey