[
https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805995#action_12805995
]
Peter Sturge commented on SOLR-1729:
------------------------------------
??...they might not all get queried at the exact same time??
I suppose this is what the explicit 'NOW' is meant to resolve -
staggered/lagged receipt/response, and, in an erzatz fashion, discrepencies in
local time sync. Since the passed-in 'NOW' is relative only to the epoch,
network latency is handled, and time-sync on any given server is assumed to be
correct.
??...multiple requets might be made to a single server for different phrases of
the distributed request that expect to get the same answers.??
As long as the same code path is followed for such requests, it should honour
the same (passed-in) 'NOW'. Are there scenarios where this is not the case? In
which case, yes, these would need to be addressed.
??...unless filter queries that use date math also respect it the counts
returned from date faceting will still potentially be non-sensical.??
Definitely filter queries will need to get/use/honour the same 'NOW' as its
corresponding query, otherwise anarchy will quickly ensue.
Can you point me toward the class(es) where filter queries' date math lives,
and I'll have a look? As filter queries are cached separately, can you think of
any potential caching issues relating to filter queries?
> 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.
