[ http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12456662 ] Michael Busch commented on LUCENE-732: --------------------------------------
You're right Hoss, the word "format" is used ambiguously in the javadoc. We could change it to * <p>In [EMAIL PROTECTED] RangeQuery}s, QueryParser tries to detect date values, e.g. <tt>date:[6/1/2005 TO 6/4/2005]</tt> * produces a range query that searches for "date" fields between 2005-06-01 and 2005-06-04. Note * that the format of the accepted input depends on [EMAIL PROTECTED] #setLocale(Locale) the locale}. * By default a date is converted into a search term using the deprecated [EMAIL PROTECTED] DateField} for compatibility reasons. * To use the new [EMAIL PROTECTED] DateTools} to convert dates, a [EMAIL PROTECTED] DateTools.Resolution} has to be set.</p> * <p>The date resolution that shall be used for RangeQueries can be set using [EMAIL PROTECTED] #setDateResolution(DateTools.Resolution)} * or [EMAIL PROTECTED] #setDateResolution(String, DateTools.Resolution)}. The former sets the default date resolution for all fields, whereas the latter can * be used to set field specific date resolutions. Field specific date resolutions take, if set, precedence over the default date resolution. * </p> * <p>If you use neither [EMAIL PROTECTED] DateField} nor [EMAIL PROTECTED] DateTools} in your index, you can create your own * query parser that inherits QueryParser and overwrites [EMAIL PROTECTED] #getRangeQuery(String, String, String, boolean)} to * use a different method for date conversion. * </p> Sounds better? Do you want me to create another patch that includes this javadoc? > Support DateTools 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, queryparser_datetools2.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]
