lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Carlson <>
Subject Re: Bug? QueryParser may not correctly interpret RangeQuery text
Date Sun, 02 Jun 2002 16:56:59 GMT
I like this idea of [GOOP:GOOP] as it gives the most flexibility. However,
this requires the field to have a known characteristic like a date field,
number field or text field correct? If you just use the static Field.Date
this would require adding a new attribute the field class? I like this idea
but I donĀ¹t know the difficulty / backward compatibility issues.

If the extra field attribute is too difficult, then I suggest we use the
nnnn-nn-nn format method so we can use the pattern to determine the data

For number fields, should this support only integers, or decimal numbers

I don't think we should use the : character, because we probably want to
support time formats in the date format. Something like 03/01/2001 at
00:01:00. Maybe something like ">" or "|" or even "->" ?

Also, inclusive vs. exclusive should be accounted for with the [ vs {
characters.  I think this might already be done, but just wanted to throw it
out there.


On 6/2/02 2:13 AM, "Brian Goetz" <> wrote:

>>> How about:
>>>  DATE = nnnn-nn-nn
>>>  NUMBER = n*
>>>  RANGE = [ DATE : DATE ] | [ NUMBER : NUMBER ]
>>> An alternate, less parse-oriented approach would be this:
>>>   RANGE = [ GOOP : GOOP ]
>>> where
>>>   GOOP = any string of letters/numbers not containing : or ].
>> I'd go for the first one as it's more explicit.  However, perhaps the
>> second approach is more extensible?
> When I first did the query parser, I defined terms by inclusion
> (stating valid characters) instead of exclusion (excluding non-term
> characters.)  Turns out I missed quite a few in the first go around,
> which taught me the lesson (again) that sometimes trying to be too
> specific is a rats nest.  What about dates like 02-Mai-2002 (not a
> typo, french for May)?  Letting DateFormat figure it out has some
> merit.
>> DateField(Date) and NumberField(int) sounds right, but wouldn't Field
>> class make more sense?
> I had in mind static methods of Field, just like Field.Text --
> Field.Date, Field.Number.   Sorry if that wasn't clear.  This seems
> an easy addition.
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message