Hi Andy
> How should I proceed from here?
I'd say this qualifies as an issue in JIRA - if you're able to come up with
a test, that would be great, but not needed
Patches are typically created against thr master-branch, but as long as you
include all needed information (version, file, ..) - we're good to go :)
-Stefan
On Oct 21, 2016 6:11 PM, "Andy C" <andycs...@gmail.com> wrote:
Upon further investigation this is a bug in Solr.
If I change the order of my interval definitions to be Negative, Zero,
Positive, instead of Negative, Positive, Zero it correctly assigns the
document with the zero value to the Zero interval.
I dug into the 5.3.1 code and 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 modified the compareStart() implementation and it seems to work correctly
now (see below). I also 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.
How should I proceed from here?
Thanks,
- Andy -
private int compareStart(FacetInterval o1, FacetInterval o2) {
if (o1.start == null) {
if (o2.start == null) {
return 0;
}
return -1;
}
if (o2.start == null) {
return 1;
}
//return o1.start.compareTo(o2.start);
int startComparison = o1.start.compareTo(o2.start);
if (startComparison == 0) {
if (o1.startOpen != o2.startOpen) {
if (!o1.startOpen) {
return -1;
}
else {
return 1;
}
}
}
return startComparison;
}
On Wed, Oct 19, 2016 at 2:47 PM, Andy C <andycs...@gmail.com> wrote:
> I have a field called "SCALE_double" that is defined as multivalued with
> the fieldType "tdouble".
>
> "tdouble" is defined as:
>
> <fieldType name="tdouble" class="solr.TrieDoubleField" precisionStep="8"
> omitNorms="true" positionIncrementGap="0"/>
>
> I have a document with the value "0" indexed for this field. I am able to
> successfully retrieve the document with the range query "SCALE_double:[0
TO
> 0]". However it doesn't match any of the interval facets I am trying to
> populate that match negative, zero, or positive values:
>
> "{!key=\"Negative\"}(*,0)",
> "{!key=\"Positive\"}(0,*]",
> "{!key=\"Zero\"}[0,0]"
>
> I assume this is some sort of precision issue with the TrieDoubleField
> implementation (if I change the Zero interval to
> "(-.0000000001,+.0000000001)" it now considers the document a match).
> However the range query works fine (I had assumed that the interval was
> just converted to a range query internally), and it fails to show up in
the
> Negative or Positive intervals either.
>
> Any ideas what is going on, and if there is anything I can do to get this
> to work correctly? I am using Solr 5.3.1. I've pasted the output from the
> Solr Admin UI query below.
>
> Thanks,
> - Andy -
>
> {
> "responseHeader": {
> "status": 0,
> "QTime": 0,
> "params": {
> "facet": "true",
> "fl": "SCALE_double",
> "facet.mincount": "1",
> "indent": "true",
> "facet.interval": "SCALE_double",
> "q": "SCALE_double:[0 TO 0]",
> "facet.limit": "100",
> "f.SCALE_double.facet.interval.set": [
> "{!key=\"Negative\"}(*,0)",
> "{!key=\"Positive\"}(0,*]",
> "{!key=\"Zero\"}[0,0]"
> ],
> "_": "1476900130184",
> "wt": "json"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "docs": [
> {
> "SCALE_double": [
> 0
> ]
> }
> ]
> },
> "facet_counts": {
> "facet_queries": {},
> "facet_fields": {},
> "facet_dates": {},
> "facet_ranges": {},
> "facet_intervals": {
> "SCALE_double": {
> "Negative": 0,
> "Positive": 0,
> "Zero": 0
> }
> },
> "facet_heatmaps": {}
> }
> }
>
