You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Andy Chillrud (JIRA)" <ji...@apache.org> on 2016/10/24 15:05:58 UTC

[jira] [Updated] (SOLR-9687) Values not assigned to all valid Interval Facet intervals in some cases

     [ https://issues.apache.org/jira/browse/SOLR-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Chillrud updated SOLR-9687:
--------------------------------
    Description: 
Using the interval facet definitions:
* \{!key=Positive}(0,*]
* \{!key=Zero}\[0,0]
* \{!key=Negative}(*,0)

A document with the value "0" in the numeric field the intervals are being applied to is not counted in the Zero interval. If I change the order of the definitions to , Negative, Zero, Positive the "0" value is correctly counted in the Zero interval.

Tracing into the 5.3.1 code the problem is in the org.apache.solr.request.IntervalFacets class. When the getSortedIntervals() method sorts the interval definitions for a field by their starting value is doesn't take into account the startOpen property. When two intervals have equal start values it needs to sort intervals where startOpen == false before intervals where startOpen == true.

In the accumIntervalWithValue() method it checks which intervals each document value should be considered a match for. It iterates through the sorted intervals and stops checking subsequent intervals when LOWER_THAN_START result is returned. If the Positive interval is sorted before the Zero interval it never checks a zero value against the Zero interval.

I compared the 5.3.1 version of the IntervalFacets class against the 6.2.1 code, and it looks like the same issue will occur in 6.2.1.






  was:
Using the interval facet definitions:
* \{!key=Negative}(*,0)
* \{!key=Zero}\[0,0]
* \{!key=Positive}(0,*]

A document with the value "0" in the numeric field the intervals are being applied to is not counted in the Zero interval. If I change the order of the definitions to Positive, Zero, Negative, the "0" value is correctly counted in the Zero interval.

Tracing into the 5.3.1 code the problem is in the org.apache.solr.request.IntervalFacets class. When the getSortedIntervals() method sorts the interval definitions for a field by their starting value is doesn't take into account the startOpen property. When two intervals have equal start values it needs to sort intervals where startOpen == false before intervals where startOpen == true.

In the accumIntervalWithValue() method it checks which intervals each document value should be considered a match for. It iterates through the sorted intervals and stops checking subsequent intervals when LOWER_THAN_START result is returned. If the Positive interval is sorted before the Zero interval it never checks a zero value against the Zero interval.

I compared the 5.3.1 version of the IntervalFacets class against the 6.2.1 code, and it looks like the same issue will occur in 6.2.1.







> Values not assigned to all valid Interval Facet intervals in some cases
> -----------------------------------------------------------------------
>
>                 Key: SOLR-9687
>                 URL: https://issues.apache.org/jira/browse/SOLR-9687
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: faceting
>    Affects Versions: 5.3.1
>            Reporter: Andy Chillrud
>
> Using the interval facet definitions:
> * \{!key=Positive}(0,*]
> * \{!key=Zero}\[0,0]
> * \{!key=Negative}(*,0)
> A document with the value "0" in the numeric field the intervals are being applied to is not counted in the Zero interval. If I change the order of the definitions to , Negative, Zero, Positive the "0" value is correctly counted in the Zero interval.
> Tracing into the 5.3.1 code the problem is in the org.apache.solr.request.IntervalFacets class. When the getSortedIntervals() method sorts the interval definitions for a field by their starting value is doesn't take into account the startOpen property. When two intervals have equal start values it needs to sort intervals where startOpen == false before intervals where startOpen == true.
> In the accumIntervalWithValue() method it checks which intervals each document value should be considered a match for. It iterates through the sorted intervals and stops checking subsequent intervals when LOWER_THAN_START result is returned. If the Positive interval is sorted before the Zero interval it never checks a zero value against the Zero interval.
> I compared the 5.3.1 version of the IntervalFacets class against the 6.2.1 code, and it looks like the same issue will occur in 6.2.1.



--
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