[ http://issues.apache.org/jira/browse/LUCENE-732?page=comments#action_12456242 ] Hoss Man commented on LUCENE-732: ---------------------------------
+1 for queryparser_datetools2.patch the only nitpick i have is with the class level javadocs... * <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 formatted using the deprecated [EMAIL PROTECTED] DateField} for compatibility reasons. * To use the new [EMAIL PROTECTED] DateTools} to format 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) ...the word "format" is used to mean two very differnet things in this paragraph, we should clean that up so it's clera that Locale determines the DateFormat QP uses when trying to parse input in [a TO b] syntax, while either DateField or DateTools are used to create the "indexed" value queried against. > 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]
