lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter S <>
Subject RE: [jira] Updated: (SOLR-1729) Date Facet now override time parameter
Date Wed, 17 Feb 2010 13:50:29 GMT



Thanks very much for making the patch files - very much appreciated!




> Date: Wed, 17 Feb 2010 13:09:27 +0000
> From:
> To:
> Subject: [jira] Updated: (SOLR-1729) Date Facet now override time parameter
> [
> Thomas Hammerl updated SOLR-1729:
> ---------------------------------
> Attachment: solr-1.4.0-solr-1729.patch
> Hi Peter!
> No problem! Thanks for contributing the code! I have attached a patch file containing
your changes to this issue. Everything compiles fine for me now.
> Thank you too! Greetings,
> Thomas
> > Date Facet now override time parameter
> > --------------------------------------
> >
> > Key: SOLR-1729
> > URL:
> > Project: Solr
> > Issue Type: Improvement
> > Components: search
> > Affects Versions: 1.4
> > Environment: Solr 1.4
> > Reporter: Peter Sturge
> > Priority: Minor
> > Attachments:,, solr-1.4.0-solr-1729.patch,
> >
> >
> > This PATCH introduces a new query parameter that tells a (typically, but not necessarily)
remote server what time to use as 'NOW' when calculating date facets for a query (and, for
the moment, date facets *only*) - overriding the default behaviour of using the local server's
current time.
> > This gets 'round a problem whereby an explicit time range is specified in a query
(e.g. timestamp:[then0 TO then1]), and date facets are required for the given time range (in
fact, any explicit time range). 
> > Because DateMathParser performs all its calculations from 'NOW', remote callers
have to work out how long ago 'then0' and 'then1' are from 'now', and use the relative-to-now
values in the parameters. If a remote server has a different opinion of NOW
compared to the caller, the results will be skewed (e.g. they are in a different time-zone,
not time-synced etc.).
> > This becomes particularly salient when performing distributed date faceting (see
SOLR-1709), where multiple shards may all be running with different times, and the faceting
needs to be aligned.
> > The new parameter is called '', and takes as a parameter a (stringified)
long that is the number of milliseconds from the epoch (1 Jan 1970 00:00) - i.e. the returned
value from a System.currentTimeMillis() call. This was chosen over a formatted date to delineate
it from a 'searchable' time and to avoid superfluous date parsing. This makes the value generally
a programatically-set value, but as that is where the use-case is for this type of parameter,
this should be ok.
> > NOTE: This parameter affects date facet timing only. If there are other areas of
a query that rely on 'NOW', these will not interpret this value. This is a broader issue about
setting a 'query-global' NOW that all parts of query analysis can share.
> > Source files affected:
> > (holds the new constant FACET_DATE_NOW)
> > getFacetDateCounts() NOW parameter modified
> > This PATCH is mildly related to SOLR-1709 (Distributed Date Faceting), but as it's
a general change for date faceting, it was deemed deserving of its own patch. I will be updating
SOLR-1709 in due course to include the use of this new parameter, after some rfc acceptance.
> > A possible enhancement to this is to detect fields, look for and match
these fields in queries (if they exist), and potentially determine automatically the required
time skew, if any. There are a whole host of reasons why this could be problematic to implement,
so an explicit parameter is the safest route.
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message