[
https://issues.apache.org/jira/browse/SOLR-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101152#comment-13101152
]
Jan Høydahl commented on SOLR-2366:
-----------------------------------
Hoss: Good comments, which need to be decided upon, including corner cases.
1)
bq.I would suggest define any case where the spec contains absolute value N
after (effective) value M where N < M as an error and fail fast.
Agree
bq.Still not sure what (if anything) should be done about overlapping ranges
that appear out of order (ie: 0,100,50..90,150 ... is that "0-100,50-90,90-150"
?)
If all gaps are specified as explicit ranges this is no ambiguity, so we could
require all gaps to be explicit ranges if one wants to use it?
2)
bq.The first three examples suggest that * will be treated as "-Infinity" and
"+Infinity" based on position (ie: the first and last ranges will be unbounded
on one end) but in the last example the wording "...100-200, 200-300 repeating
until max" seems inconsistent with that.
Agree. The 0,10,50,+50,+100,* example would create infinite gaps which would be
less than desireable. But 0,10,50,+50,+100,500 would give repeating 100-gaps
until upper bound 500, while 0,10,50,+50,+100,500,* would in addition give a
last range 500-*. That was the intentional syntax.
bq.If we want to support the idea of "repeat the last increment continuously"
that should be with it's own "repeat" syntax such as the "..." (three dots) i
suggested in comment "17/Feb/11 23:50" above. I would argue that this should
only be legal after an increment and before a concrete value (ie:
0,+10,...,100). Requiring it to follow an increment seems like a given
(otherwise what exactly are you repeating?) requiring that it be followed by an
absolute value is based on my concern that if it's the last item in the spec
(or the last item before *) it results in an infinite number of ranges.
Agree. Alternatively, if Solr could compute myField.max(), the useful value of
"*" could be computed a bit smarter, but that would probably be hard to scale
in a multi-shard setting.
bq.That seems like it isn't specific enough about what is/isn't going to be
allowed – particularly since all of the facet.range params can be specified on
a per field basis.
Didn't really think much about the global params. Silently not caring about
gap, begin, end, other would be one way to go, but then the error feedback is
not explicit in case of misunderstanding; the user will see that he does not
get back what he thought, and start reading the documentation :)
I have no good answer to this, other than inventing some syntax. The default
could be that facet.range.spec respects the global values for start and end,
but also allow explicitly overriding start and end values as part of spec with
a special syntax.
The following params would result in ranges 0-1, 1-2, 2-3, 3-5, 5-10 :
{noformat}
facet.range.start=0
facet.range.end=10
facet.range.gap=2
f.bedrooms.facet.range.spec=1,2,3,5
{noformat}
But these params would result in the same ranges because we specify start and
end with a special syntax N.. for start and ..M for end:
{noformat}
facet.range.start=100
facet.range.end=200
facet.range.gap=10
f.bedrooms.facet.range.spec=0..,1,2,3,5,..10
{noformat}
This would be equivalent with adding the two params
f.bedrooms.facet.range.start=0&f.bedrooms.facet.range.end=10, which could then
still be allowed as an alternative. If the first value of the spec is not an
N.., we'll require a facet.range.start. If the last value of the spec is not
..M, we'll require facet.range.end.
Also, it must not be allowed to specify both a global facet.range.gap and a
global facet.range.spec.
Would this be a good "compromise"? :-) My primary reason for suggesting this is
to give users a terse, intuitive syntax for ranges.
4)
bq.Should all ranges produced by facet.range.spec be considered "gap" ranges?
even the ones with no lower/upper bound?
Good question. I think the values facet.range.include=upper/lower is clear.
Outer/edge would need some more work/definition.
> Facet Range Gaps
> ----------------
>
> Key: SOLR-2366
> URL: https://issues.apache.org/jira/browse/SOLR-2366
> Project: Solr
> Issue Type: Improvement
> Reporter: Grant Ingersoll
> Priority: Minor
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2366.patch, SOLR-2366.patch
>
>
> There really is no reason why the range gap for date and numeric faceting
> needs to be evenly spaced. For instance, if and when SOLR-1581 is completed
> and one were doing spatial distance calculations, one could facet by function
> into 3 different sized buckets: walking distance (0-5KM), driving distance
> (5KM-150KM) and everything else (150KM+), for instance. We should be able to
> quantize the results into arbitrarily sized buckets. I'd propose the syntax
> to be a comma separated list of sizes for each bucket. If only one value is
> specified, then it behaves as it currently does. Otherwise, it creates the
> different size buckets. If the number of buckets doesn't evenly divide up
> the space, then the size of the last bucket specified is used to fill out the
> remaining space (not sure on this)
> For instance,
> facet.range.start=0
> facet.range.end=400
> facet.range.gap=5,25,50,100
> would yield buckets of:
> 0-5,5-30,30-80,80-180,180-280,280-380,380-400
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
