[
https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966488#action_12966488
]
Peter Karich commented on SOLR-1729:
------------------------------------
*regarding: 1.4.1*
Hmmh, today download.carrot2.org is down and I had to delete contrib/clustering
to do the build after the patch. which does not apply cleanly (strange that it
appled yesterday):
solr1.4.1$ patch -p0 < solr-1.4.0-solr-1729.patch
patching file src/java/org/apache/solr/handler/component/FacetComponent.java
patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java
solr1.4.1$ patch -p0 < solr-1.4.0-solr-1709.patch
patching file src/java/org/apache/solr/handler/component/FacetComponent.java
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java
Reversed (or previously applied) patch detected! Assume -R? [n] y
Hunk #3 succeeded at 251 (offset -1 lines).
Or is this ok?? Because then, all tests would pass ...
*regarding branch3x*
both patches do not apply cleanly. SOLR-1709 fails also without SOLR-1729
solr_branch_3x/solr$ patch -p0 < solr-1.4.0-solr-1709.patch
patching file src/java/org/apache/solr/handler/component/FacetComponent.java
Hunk #1 succeeded at 240 (offset 2 lines).
Hunk #2 succeeded at 267 with fuzz 2 (offset 7 lines).
Hunk #3 FAILED at 436.
1 out of 3 hunks FAILED -- saving rejects to file
src/java/org/apache/solr/handler/component/FacetComponent.java.rej
patching file src/java/org/apache/solr/handler/component/ResponseBuilder.java
Reversed (or previously applied) patch detected! Assume -R? [n] y
Hunk #2 FAILED at 61.
Hunk #3 FAILED at 252.
2 out of 3 hunks FAILED -- saving rejects to file
src/java/org/apache/solr/handler/component/ResponseBuilder.java.rej
> 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,
> solr-1.4.0-solr-1729.patch, UnInvertedField.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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
