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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> 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:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
