lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Murzaku <murz...@yahoo.com>
Subject Re: Bug? QueryParser may not correctly interpret RangeQuery text
Date Sun, 02 Jun 2002 18:30:12 GMT
How about just the SQL "BETWEEN ... AND ..."?

Maybe we could even throw in full support for SQL like
SELECT, WHERE, etc. As far as I remember, JavaCC used
to have an SQL parser as well, so, I assume we would
just need the translation to a Lucene query. I am sure
everybody would appreciate using some syntax with
which they are already familiar.

--- Peter Carlson <carlson@bookandhammer.com> wrote:
> 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
> type.
> 
> For number fields, should this support only
> integers, or decimal numbers
> too? 
> 
> 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.
> 
> --Peter
> 
> 
> On 6/2/02 2:13 AM, "Brian Goetz" <brian@quiotix.com>
> 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:  
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message