incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David E. Wheeler" <da...@kineticode.com>
Subject Re: [lucy-dev] Simplifying the Query Parser
Date Mon, 18 Apr 2011 21:16:33 GMT
On Apr 18, 2011, at 12:41 PM, Marvin Humphrey wrote:

> The 'mailto:' example is the only one that's problematic with #4, the
> NoMatchQuery option, though.  And it's pretty esoteric -- how many times do
> people actually type/paste mailto links into search boxes?

Not often, though it happens. I wouldn't worry overmuch about it.

> The others are all solvable by tightening up the parser:
> 
>  * Currently field names must match /[0-9A-Za-z_]+/.  We should require
>    them to be identifiers, i.e. they must not start with a number:
>    /[A-Za-z_][0-9A-Za-z_]*/
>  * QueryParser should use single-token lookahead to enforce that field name
>    constructs must be followed by something sensible.

And if it's not, what then? What if it's sensible but the field doesn't exist (or is private)?

> I think we ought to consider the fact that QueryParser turns
> 'PHP::Interpreter' into field name 'PHP' and term ':Interpreter' a bug, and
> address it with bugfixes rather than a new feature.

+1 to fixing bugs first.

> The behavior after
> applying the fixes will be to produce a phrase -- just as with option #3 --
> but the internals of QueryParser will be cleaner.

Excellent.

>> And at what point would the application of one of the above four solutions
>> be applied? I can see arguments for 0.1.0 and 0.2.0.
> 
> This issue should not block 0.1.0, which is almost done.  

Well, if the handling of PHP::Interpreter is a bug, should that not be fixed before 0.1.0?

> We'd probably be voting on 0.1.0 now were it not for the interesting traffic
> on lucy-dev diverting our attention. :)

Sorry, I suck.

David



Mime
View raw message