[
https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834721#action_12834721
]
Thomas Hammerl edited comment on SOLR-1729 at 2/17/10 10:25 AM:
----------------------------------------------------------------
As in SOLR-1709 I'm not able to apply this patch to solr-1.4.0 without getting
a compile error:
{noformat}
[javac]
/home/systemone/Desktop/solr-1.4.0/src/java/org/apache/solr/request/SimpleFacets.java:257:
getCounts(org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String)
in org.apache.solr.request.UnInvertedField cannot be applied to
(org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String,java.lang.String)
[javac] counts = uif.getCounts(searcher, base, offset, limit,
mincount,missing,sort,prefix, facetSortOrder);
{noformat}
Is it possible that you have forgotten to include your changes to
org.apache.solr.request.UnInvertedField? The method getCounts is missing the
facetSortOder parameter you are trying to pass in SimpleFacets.java.
I would be happy to attach a working patch-file to this issue.
was (Author: thomas.hammerl):
As in SOLR-1709 I'm not able to apply this patch to solr-1.4.0 without
getting a compile error:
{noformat}
[javac]
/home/systemone/Desktop/solr-1.4.0/src/java/org/apache/solr/request/SimpleFacets.java:257:
getCounts(org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String)
in org.apache.solr.request.UnInvertedField cannot be applied to
(org.apache.solr.search.SolrIndexSearcher,org.apache.solr.search.DocSet,int,int,java.lang.Integer,boolean,java.lang.String,java.lang.String,java.lang.String)
[javac] counts = uif.getCounts(searcher, base, offset, limit,
mincount,missing,sort,prefix, facetSortOrder);
{noformat}
Is it possible that you have forgotten to include your changes to
org.apache.solr.request.UnInvertedField? The method getCounts is missing the
facetSortOder parameter you are trying to pass in SimpleFacets.java.
I would be happy to attach a working patch-file to this issue.
> 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.
