[jira] Commented: (SOLR-71) New support for Date Math when adding/quering date fields

[Bertrand Delacretaz (JIRA)]

[ 
http://issues.apache.org/jira/browse/SOLR-71?page=comments#action_12450981 ] 

Bertrand Delacretaz commented on SOLR-71:
-

This looks like a very useful feature!

 New support for Date Math when adding/quering date fields
 ---

 Key: SOLR-71
 URL: http://issues.apache.org/jira/browse/SOLR-71
 Project: Solr
  Issue Type: New Feature
  Components: search, update
Reporter: Hoss Man
 Assigned To: Hoss Man
 Attachments: DateMath.patch


 New utility class and changes to DateField to support syntax like the 
 following...
   startDate:[* TO NOW]
   startDate:[* TO NOW/DAY+1DAY]
   expirationDate:[NOW/DAY TO *]
   reviewDate:[NOW/DAY-1YEAR TO NOW/DAY]
   validDate:[NOW/MONTH TO NOW/MONTH+1MONTH-1MILLISECOND]
 ...where + and - mean what you think, and /UNIT rounds down to the nearest 
 UNIT.  The motivation for this being that date range queries like these are 
 usefull for filters, but being date sensitve can't currently be baked in to 
 a config as default params.
 a nice side effect of the implimentation, is that timestamp fields can be 
 done with a document is added by using...
field name=myTimestampFieldNOW/field
 ...and Solr will compute the value when adding the document ... if we add 
 default values to the schema.xml even that won't be neccessary.
 Comments?  
 (I'd be particularly gratefull if smarter people then I would sanity check my 
 use of ThreadLocal for managing the DateFormat in DateField ... i've never 
 used ThreadLocal before.  Any general comments on the syntax would also be 
 appreciated: This left-to-right syntax seemed more intuative to write (and 
 easier to parse) then some of the other syntaxes I'd considered)

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

Re: [jira] Commented: (SOLR-71) New support for Date Math when adding/quering date fields

[Chris Hostetter]

:  - initialValue doesn't need to be synchronized... it's just that way in
: the javadoc example because they were incrementing a global counter

Ah, good eye.

:  - the trick you are trying in the ThreadLocalDateFormat aren't
: necessary.  no method will be called until the constructor has
: completed.  the java memory model also ensures that you see a completely
: constructed object from another thread, even if you haven't
: synchronized.  The extra variable won't hurt either... the JVM will
: completely optimize it away (so this is just an FYI).

I think you are giving me more credit then i deserve ... what trick do you
think i'm trying to accomplish?

You're talking about the local tmp formatter and which is then assigned
to proto at the end? ... that wasn't out of any fear that it would be
used before i set the timezeon, it was just because my inate distaste for
declaring member variables with concrete types wouldn't let write
SimpleDateFormat proto; ... so i could either use a tmp var, or cast it
to call setTimeZone -- and if there is one thing i loath more then member
vars with concrete types, it's casting (I was very bitter to discover that
Clonable isn't a parametric type in java5 ... i relly wanted to write...

  private static class ThreadLocalDateFormat extends ThreadLocalDateFormat {
ClonableDateFormat proto;
public ThreadLocalDateFormat() {
...
}
protected synchronized DateFormat initialValue() {
  return proto.clone();
}
  }




-Hoss