[
https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Sturge updated SOLR-1729:
-------------------------------
Attachment: FacetParams.java
SimpleFacets.java
These are the source files affected for this patch.
Apologies for not creating a PATCH file - my tortoise svn is not working for
creating patch files.
If anyone would like to create a patch from these, that would be
extraordinarily kind of you!
Diff: (trunk: 1.4 Release)
FacetParams.java:
Add at line 179:
/**
* String that tells the date facet counter what time to use as 'now'.
*
* The value of this parameter, if it exists, must be a stringified long
* of the number of milliseconds since the epoch (milliseconds since 1 Jan
1970 00:00).
* System.currentTimeMillis() provides this.
*
* The DateField and DateMathParser work out their times relative to 'now'.
* By default, 'now' is the local machine's System.currentTimeMillis().
* This parameter overrides the local value to use a different time.
* This is very useful for remote server queries where the times on the
querying
* machine are skewed/different than that of the date faceting machine.
* This is a date.facet global query parameter (i.e. not per field)
* @see DateMathParser
* @see DateField
*/
public static final String FACET_DATE_NOW = "facet.date.now";
SimpleFacets.java:
Change at line 551:
- final Date NOW = new Date();
+ final Date NOW = new Date(params.get(FacetParams.FACET_DATE_NOW) != null
? Long.parseLong(params.get("facet.date.now")) : System.currentTimeMillis());
> Date Facet now override time parameter
> --------------------------------------
>
> Key: SOLR-1729
> URL: https://issues.apache.org/jira/browse/SOLR-1729
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.4
> Environment: Solr 1.4
> Reporter: Peter Sturge
> Priority: Minor
> Attachments: FacetParams.java, SimpleFacets.java
>
>
> 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 facet.date.xxx 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 'facet.date.now', 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:
> FacetParams.java (holds the new constant FACET_DATE_NOW)
> SimpleFacets.java 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 facet.date 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
> facet.date.now 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.
