lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <>
Subject [jira] Commented: (LUCENE-732) Support DateTools in QueryParser
Date Fri, 08 Dec 2006 01:48:22 GMT
    [ ] 
Michael Busch commented on LUCENE-732:

You're right Hoss, the word "format" is used ambiguously in the javadoc. We could change it

 * <p>In {@link 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.
 * that the format of the accepted input depends on {@link #setLocale(Locale) the locale}.

 * By default a date is converted into a search term using the deprecated {@link DateField}
for compatibility reasons.
 * To use the new {@link DateTools} to convert dates, a {@link DateTools.Resolution} has to
be set.</p> 
 * <p>The date resolution that shall be used for RangeQueries can be set using {@link
 * or {@link #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 {@link DateField} nor {@link DateTools} in your index, you
can create your own
 * query parser that inherits QueryParser and overwrites {@link #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:
>             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 {@link #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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message