You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2014/09/06 01:17:29 UTC
[jira] [Comment Edited] (SOLR-6386) make secondary ordering of
facet.field values (and facet.pivot?) consistently deterministic
[ https://issues.apache.org/jira/browse/SOLR-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100108#comment-14100108 ]
Erick Erickson edited comment on SOLR-6386 at 9/5/14 11:17 PM:
---------------------------------------------------------------
You're probably right. I added some logging at the error to dump the responses being compared
and pasted them below. Two interesting things:
1> one response has maxScore and the other does not. Not sure that would be significant or not.
2> Your workaround is interesting. I think there's another bug here, see the responses for
2010-05-03T11:00:00Z below. At least one problem is that there are counts of 0 returned in one
case but not in the other. Haven't even looked at which one this happens to (expected or actual),
got some errands to run.
I'm also looking two other bugs, SOLR-6154 and SOLR-6187 both having to do with mincount
and distributed search not being respected. Seems ... ummm... at least it's in the vicinity ;). I'll
look some more later.
Response A
{responseHeader={status=0,QTime=8},response={numFound=68,start=0,maxScore=1.0,docs=[]},facet_counts={facet_queries={},facet_fields=
{a_n_tdt={2010-05-03T11:00:00Z=2,
2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,1970-01-01T00:00:00Z=0,2009-03-13T13:23:01.248Z=0,2010-04-15T05:45:19.616Z=0,2010-04-20T06:55:27.232Z=0,2010-04-20T10:55:45.152Z=0,2010-04-20T10:59:59.104Z=0,2010-04-27T16:01:01.44Z=0,2010-05-02T07:51:54.624Z=0,2010-05-02T10:59:46.816Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T07:10:00.704Z=0,2010-05-03T10:57:12.192Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:25:50.08Z=0,2010-05-05T10:56:25.088Z=0,2010-05-05T10:59:58.08Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
Response B
{responseHeader={status=0,QTime=5},response={numFound=68,start=0, docs=[]},facet_counts={facet_queries={},facet_fields={a_n_tdt={
2010-05-03T11:00:00Z=2
,2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,2010-04-20T11:00:00Z=0,2010-05-02T11:00:00Z=0,
2010-05-03T11:00:00Z=0,
2010-05-05T11:00:00Z=0,2010-04-20T10:59:59.104Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:59:58.08Z=0,2010-04-20T10:55:45.152Z=0,2010-05-02T10:59:46.816Z=0,2010-05-03T10:57:12.192Z=0,2010-05-05T10:56:25.088Z=0,2010-04-20T06:55:27.232Z=0,2010-05-02T07:51:54.624Z=0,2010-05-03T07:10:00.704Z=0,2010-05-05T10:25:50.08Z=0,2010-04-15T05:45:19.616Z=0,2010-04-27T16:01:01.44Z=0,2009-03-13T13:23:01.248Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
was (Author: erickerickson):
You're probably right. I added some logging at the error to dump the responses being compared
and pasted them below. Two interesting things:
1> one response has maxScore and the other does not. Not sure that would be significant or not.
2> Your workaround is interesting. I think there's another bug here, see the responses for
2010-05003T11:00:00Z below. At least one problem is that there are counts of 0 returned in one
case but not in the other. Haven't even looked at which one this happens to (expected or actual),
got some errands to run.
I'm also looking two other bugs, SOLR-6154 and SOLR-6187 both having to do with mincount
and distributed search not being respected. Seems ... ummm... at least it's in the vicinity ;). I'll
look some more later.
Response A
{responseHeader={status=0,QTime=8},response={numFound=68,start=0,maxScore=1.0,docs=[]},facet_counts={facet_queries={},facet_fields=
{a_n_tdt={2010-05-03T11:00:00Z=2,
2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,1970-01-01T00:00:00Z=0,2009-03-13T13:23:01.248Z=0,2010-04-15T05:45:19.616Z=0,2010-04-20T06:55:27.232Z=0,2010-04-20T10:55:45.152Z=0,2010-04-20T10:59:59.104Z=0,2010-04-27T16:01:01.44Z=0,2010-05-02T07:51:54.624Z=0,2010-05-02T10:59:46.816Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T07:10:00.704Z=0,2010-05-03T10:57:12.192Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:25:50.08Z=0,2010-05-05T10:56:25.088Z=0,2010-05-05T10:59:58.08Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
Response B
{responseHeader={status=0,QTime=5},response={numFound=68,start=0, docs=[]},facet_counts={facet_queries={},facet_fields={a_n_tdt={
2010-05-03T11:00:00Z=2
,2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,2010-04-20T11:00:00Z=0,2010-05-02T11:00:00Z=0,
2010-05-03T11:00:00Z=0,
2010-05-05T11:00:00Z=0,2010-04-20T10:59:59.104Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:59:58.08Z=0,2010-04-20T10:55:45.152Z=0,2010-05-02T10:59:46.816Z=0,2010-05-03T10:57:12.192Z=0,2010-05-05T10:56:25.088Z=0,2010-04-20T06:55:27.232Z=0,2010-05-02T07:51:54.624Z=0,2010-05-03T07:10:00.704Z=0,2010-05-05T10:25:50.08Z=0,2010-04-15T05:45:19.616Z=0,2010-04-27T16:01:01.44Z=0,2009-03-13T13:23:01.248Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
> make secondary ordering of facet.field values (and facet.pivot?) consistently deterministic
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-6386
> URL: https://issues.apache.org/jira/browse/SOLR-6386
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Erick Erickson
>
> as a fluke of how the SOLR-2894 patch evolved, it wound up adding a bit of testing of distributed facet.field on date fields (see [r1617789 changes to TestDistributedSearch|https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/test/org/apache/solr/TestDistributedSearch.java?r1=1617789&r2=1617788&pathrev=1617789]) ... but this started triggering some random failures due to facet constraints with identical values being sorted differently between the distributed query and the single node control query.
> We should make the facet.field (and facet.pivot) code order constraints with tied counts consistently regardless of whether it's a distrib search or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org