Brian, I 100% agree with you about having actual field types, I just don't know what the ramifications are and haven't looked. I was hoping Doug would chime in and make it easy for us.
It would be nice to have it working though. I vote +1 for " TO " And for the format into date then number methodology seems great to me. If we want to support full on terms we could also say if it doesn't just have digits then its just a term. So Date -> Number -> Term. --Peter On 6/5/02 12:20 AM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: >> I guess from my perspective we are at >> >> field:[<goop>-><goop>] >> >> The delimiter is not yet defined, but the options currently discussed are >> - >> -> >> ; >> : >> | >>> >> >> The problem with - and : is that they may be part of a date format. > > How about " TO " as the delimiter? > >> The action taken by the QueryParser would depend on the type of field we >> were using (if that were an easy change). For Date fields, it would convert >> the <goop> to a Date using the SimpleDateFormat and try to guess the format >> (I think it will handle the ISO 8601 formats). > > Or, what about this: try to parse it as a date as above, using a > DateFormat. If that fails, try to parse it as a number. > > I still want to see Date and Number fields supported as basic types in > the Field class, rather than "use a String in this magic date format". > > > -- > 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]>
