You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Peter Carlson <ca...@bookandhammer.com> on 2002/07/11 19:47:36 UTC

Re: Bug? QueryParser may not correctly interpret RangeQuery text

I am finally getting a few moments to look at this.

Should date fields be tokenized? Current the Field.Keyword(String, Date)
constructor has the Date tokenized, but this doesn't seem right.

--Peter


On 6/24/02 5:09 PM, "Brian Goetz" <br...@quiotix.com> wrote:

>> Just curious what the status of this issue is, as the discussion seems
>> to have stopped.
> 
> I checked in a first cut at this facility:
> 
> - Field.Keyword(String, Date) "constructor", which uses DateField format;
> - Extensions to query parser as discussed earlier;
> - test cases.
> 
> More work needs to be done on the date parsing code, but its pretty
> much separated from the query parsing now.  Right now, we accept dates
> of the form "nn/nn/nn", as supported by
> DateFormat.getDateInstance(DateFormat.SHORT).  I think we want to be
> more flexible about this, and also support date-times as well (the new
> parser stuff includes support for quoted strings inside range expressions,
> so we can include things with spaces that way.)
> 
> Also, we talked about adding numeric ranges too.  First we'd need a
> NumberField class and "constructor", similar to DateField, and then
> we'd want to use NumberFormat to see if the elements in the range query
> are of the right format.
> 
> I'd like to hand off the specifics of date format parsing to someone
> else, since I'm pretty pressed for time; I've done the part that
> involves the parser, which is the high-risk part.
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Bug? QueryParser may not correctly interpret RangeQuery text

Posted by Brian Goetz <br...@quiotix.com>.
> Should date fields be tokenized? Current the Field.Keyword(String, Date)
> constructor has the Date tokenized, but this doesn't seem right.

No, I thought I copied from Keyword so it wouldn't be tokenized.  Did
I screw it up?

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>