Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: 207.173.203.201 is neither permitted
 nor denied by domain of david@kineticode.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: "David E. Wheeler" <david@kineticode.com>
In-Reply-To: <4DA90CA0.6010509@peknet.com>
Date: Sat, 16 Apr 2011 09:05:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC540E2E-3612-4A05-8940-9055FFA7C2DF@kineticode.com>
References: <D3E8E7A4-36DA-431F-847C-D2391FDDB637@kineticode.com>
 <4DA90CA0.6010509@peknet.com>
To: lucy-dev@incubator.apache.org
Subject: Re: [lucy-dev] Simplifying the Query Parser

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.

Best,

David