[
https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970544#action_12970544
]
Peter Karich commented on SOLR-1729:
------------------------------------
Yonik,
thanks for the update. I refreshed my sources (now trunk) to rev 1044745. But
the patch does not cleanly apply* for SearchHandler.
Am I doing something stupid here?
Regards,
Peter.
*
pathxy/solr_branch_3x$ patch -p0 < SOLR-1729.patch
patching file solr/src/test/test-files/solr/conf/schema12.xml
patching file
solr/src/test/org/apache/solr/search/function/TestFunctionQuery.java
Hunk #1 succeeded at 301 (offset -17 lines).
patching file
solr/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java
patching file
solr/src/test/org/apache/solr/handler/component/TermVectorComponentTest.java
patching file solr/src/java/org/apache/solr/core/QuerySenderListener.java
patching file solr/src/java/org/apache/solr/request/SimpleFacets.java
Hunk #1 succeeded at 64 (offset -9 lines).
Hunk #2 succeeded at 620 (offset -200 lines).
Hunk #3 succeeded at 630 (offset -200 lines).
Hunk #4 succeeded at 645 (offset -200 lines).
Hunk #5 succeeded at 803 (offset -200 lines).
patching file solr/src/java/org/apache/solr/handler/component/SearchHandler.java
Hunk #1 FAILED at 192.
Hunk #2 succeeded at 255 (offset -36 lines).
1 out of 2 hunks FAILED -- saving rejects to file
solr/src/java/org/apache/solr/handler/component/SearchHandler.java.rej
patching file
solr/src/java/org/apache/solr/handler/component/ResponseBuilder.java
Hunk #2 succeeded at 67 (offset -1 lines).
patching file solr/src/java/org/apache/solr/spelling/SpellCheckCollator.java
patching file solr/src/java/org/apache/solr/util/TestHarness.java
Hunk #2 succeeded at 320 (offset -9 lines).
Hunk #3 succeeded at 335 (offset -9 lines).
patching file solr/src/java/org/apache/solr/util/DateMathParser.java
patching file solr/src/webapp/src/org/apache/solr/servlet/SolrServlet.java
patching file
solr/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
Hunk #1 succeeded at 241 (offset 4 lines).
Hunk #2 succeeded at 255 (offset 4 lines).
Hunk #3 succeeded at 283 (offset 4 lines).
patching file
solr/src/webapp/src/org/apache/solr/servlet/DirectSolrConnection.java
Hunk #2 succeeded at 170 (offset -16 lines).
Hunk #3 succeeded at 185 with fuzz 1 (offset -16 lines).
patching file
solr/src/webapp/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
Hunk #1 succeeded at 32 with fuzz 1 (offset -9 lines).
Hunk #2 succeeded at 138 (offset -11 lines).
Hunk #3 succeeded at 156 (offset -77 lines).
> 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, SOLR-1729.patch, 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]
