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]>