[
http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12454469 ]
Michael Busch commented on LUCENE-732:
--------------------------------------
Actually it is documented in the QueryParser how to use a different format for
dates:
...
* feature also assumes that your index uses the [EMAIL PROTECTED]
DateTools} class to store dates.
* If you use a different format and you still want QueryParser
* to turn local dates in range queries into valid queries you need to
create your own
* query parser that inherits QueryParser and overwrites
* [EMAIL PROTECTED] #getRangeQuery(String, String, String, boolean)}.
...
And the javadoc of DateField says:
Deprecated. If you build a new index, use DateTools instead. This class is
included for use with existing indices and will be removed in a future release.
So the question is in how many future releases we want to support DateField. If
we still want to support it in 2.1 I agree to Hoss that his suggestion would be
a nice and clean way to do that and I can easily change the patch accordingly.
It avoids having another option in QueryParser.
> Use DateTools instead of deprecated DateField in QueryParser
> ------------------------------------------------------------
>
> Key: LUCENE-732
> URL: http://issues.apache.org/jira/browse/LUCENE-732
> Project: Lucene - Java
> Issue Type: Improvement
> Components: QueryParser
> Reporter: Michael Busch
> Assigned To: Michael Busch
> Priority: Minor
> Attachments: queryparser_datetools.patch
>
>
> The QueryParser currently uses the deprecated class DateField to create
> RangeQueries with date values. However, most users probably use DateTools to
> store date values in their indexes, because this is the recommended way since
> DateField has been deprecated. In that case RangeQueries with date values
> produced by the QueryParser won't work with those indexes.
> This patch replaces the use of DateField in QueryParser by DateTools. Because
> DateTools can produce date values with different resolutions, this patch adds
> the following methods to QueryParser:
> /**
> * Sets the default date resolution used by RangeQueries for fields for
> which no
> * specific date resolutions has been set. Field specific resolutions can
> be set
> * with [EMAIL PROTECTED] #setDateResolution(String, DateTools.Resolution)}.
> *
> * @param dateResolution the default date resolution to set
> */
> public void setDateResolution(DateTools.Resolution dateResolution);
>
> /**
> * Sets the date resolution used by RangeQueries for a specific field.
> *
> * @param field field for which the date resolution is to be set
> * @param dateResolution date resolution to set
> */
> public void setDateResolution(String fieldName, DateTools.Resolution
> dateResolution);
> (I also added the corresponding getter methods).
> Now the user can set a default date resolution used for all fields or, with
> the second method, field specific date resolutions.
> The initial default resolution, which is used if the user does not set a
> different resolution, is DateTools.Resolution.DAY.
> Please let me know if you think we should use a different resolution as
> default.
> I extended TestQueryParser to test this new feature.
> All unit tests pass.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
