Does this have better performance than using DateFilter?
Regards,
Hui
-----Original Message-----
From: Michael Barry [mailto:[EMAIL PROTECTED]]
Sent: Wed 1/22/2003 10:27 AM
To: Lucene Users List
Cc:
Subject: Re: Range queries
I utilize the earlier version and queries such as this work fine with
QueryParser:
field:[ 20030120 - 20030125 ]
of course the back-end indexer canonocalizes all date fields to YYYYMMDD.
The front-end search code is responsible for canonocalizing the user inputed
dates to YYYYMMDD. I think the key here would be either to not allow
users to
enter free-form dates (provide some type of UI element to enter year, month,
day seperately) or give some copy stating dates should be in YYYYMMDD
format.
-Mike.
Erik Hatcher wrote:
> Unfortunately I don't believe date field range queries work with
> QueryParser, or at least not human-readable dates.
>
> Is that correct?
>
> I think it supports date ranges if they are turned into a numeric
> format, but no human would type that kind of query in. I'm sure
> supporting true date range queries gets tricky with locale issues and
> such too.
>
> Erik
>
>
> On Wednesday, January 22, 2003, at 09:19 AM, Terry Steichen wrote:
>
>> Tatu,
>>
>> I believe the range query syntax for the latest Lucene version is
>> "field:[lower TO upper]", or "field:[null TO upper]", or
>> "field:[lower TO
>> null]". In earlier versions replace "TO" with a dash ("-").
>>
>> I also believe that multiple wildcards ("?" and/or "*") work just
>> fine (as
>> long as they aren't the first character of the term).
>>
>> HTH,
>>
>> Terry
>>
>> ----- Original Message -----
>> From: "Tatu Saloranta" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Wednesday, January 22, 2003 11:48 PM
>> Subject: Range queries
>>
>>
>>> My apologies if this is a FAQ (which is possible as I am new to Lucene,
>>> however, I tried checking the web page for the answer).
>>>
>>> I read through the "Query syntax" web page first, and then checked the
>>> matching query classes. It seems like query syntax page is missing some
>>> details; the one I was wondering about was the range query. Since query
>>> parser seems to construct these queries, I guess they have been
>>
>> implemented,
>>
>>> even though syntax page didn't explain them. Is that correct?
>>>
>>> Looking at QueryParser, it seems that inclusive range query uses [
>>> and ],
>>
>> and
>>
>>> exclusive query { and }? Is this right? And does it expect exactly two
>>> arguments?
>>> Also, am I right in assuming that range uses lexiographic ordering, so
>>
>> that it
>>
>>> basically includes all possible words (terms) between specified terms
>>
>> (which
>>
>>> will work ok with numbers/dates as long as they have been padded with
>>
>> zeroes
>>
>>> or such)?
>>>
>>> Another question I have is regarding wildcard search. Page mentions
>>> that
>>
>> there
>>
>>> is a restriction that search term can not start with a wild card (as
>>> that
>>> would render index useless I guess... would need to full scan?).
>>> However,
>>
>> it
>>
>>> doesn't mention if multiple wildcards are allowed? All the example
>>> cases
>>
>> just
>>
>>> have single wild card?
>>>
>>> Sorry for the newbie questions,
>>>
>>> -+ Tatu +-
>>>
>>> ps. Thanks for the developers for the neat indexing engine. I am
>>> currently
>>> evaluating it for use in a large-scale enterprise content management
>>
>> system.
>>
>>>
>>>
>>> --
>>> 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]>
>>
>>
>
>
> --
> 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]>
<<winmail.dat>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
