lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David E. Wheeler" <>
Subject Re: [lucy-dev] Simplifying the Query Parser
Date Sat, 16 Apr 2011 16:05:18 GMT
On Apr 15, 2011, at 8:27 PM, Peter Karman wrote:

> This, I'm not so sure about. At least, it should be configurable, with a
> 'strict' flag or similar, which if enabled, would throw errors if 'foo' was not
> a defined field. Otherwise, depending on the user, we're in the realm of silent
> failure rather than gracious host.

That just trades one level of complexity (heed_colons) for another (strict).

> Do we even have a feature for public/private fields atm?

Yes, Marvin says it will search only those you list in the constructor, unless you have heed_colons
on and someone specifies a field not listed.

> So what kind of parser should our QueryParser be? I don't think it can be all
> things to all users, so being most things to most users is actually a pretty
> good goal, imo.

Agreed, but I think that the choice as to the kind of parser it "should be" was made quite
a long time ago. I think it makes a lot of sense, though, for tool builders like you, to have
an alternate, stricter parser that's easier to build on top of reliably.

> I think the focus on reliable, flexible *Query classes has been a good design
> choice to date, because it means that it is quite straightforward to roll your
> own query parser (as I have done), entirely suited to your application's needs,
> sidestepping the Lucy QueryParser altogether. That's good library design, imo.

So maybe there isn't a need for a strict parser?

> I agree that Lucy QueryParser should get simpler over time, by losing features,
> but not convinced that the behavior you're proposing actually does that. I'm
> happy to be convinced though.

Given the audience it currently targets (web search box users), I think it makes sense to
try to adhere to the principal of least astonishment.



View raw message