[
https://issues.apache.org/jira/browse/SOLR-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729957#comment-14729957
]
Tomás Fernández Löbbe commented on SOLR-7795:
---------------------------------------------
bq. I have described a new output format in SOLR-6352 which could be used for
this feature instead of having separate "counts" and "intervals". Perhaps we
introduce that format first (maybe independently of hanging stats off of
ranges) and then merge this feature into the same format?
I think that format can be changed regardless of if we use "counts"/"intervals"
or all together. Are you saying you would prefer merging everything under
"counts"?
Instead of:
{code}
"facet_ranges":{
"price":{
"counts":[
{
"start" : "0.0",
"count" : "7"
},
{
"start" : "10.0",
"count" : "9"
}
],
"intervals": [
{
"key" : "[100,200]",
"count" : "20"
},
...
{code}
Something like:
{code}
"facet_ranges":{
"price":{
"counts":[
{
"start" : "0.0",
"count" : "7"
},
{
"start" : "10.0",
"count" : "9"
},
{
"key" : "[100,200]",
"count" : "20"
},
...
{code}
Maybe also change the "start" to "key" for regular range faceting, and use the
range rather than the start value?
{code}
"facet_ranges":{
"price":{
"counts":[
{
"key" : "[0.0,10.0)", <-- This range comes from start,
end, gap parameters
"count" : "7"
},
{
"key" : "[10.0,20.0)", <-- This range comes from
start, end, gap parameters
"count" : "9"
},
{
"key" : "[100,200]", <-- This range comes from a
specific interval
"count" : "20"
},
...
{code}
One issue with this is that "before", "all" and "after" may become more
confusing.
bq. Also, can the "f.price.facet.range.set" params work as local params now?
The local param is supported (will add a test case), however due to SOLR-2798
you can only specify one interval using them. This works:
{code:java}
assertQ(req("q", "*:*", "facet", "true",
"facet.range", "{!facet.range.set='[0,2]'}test_i_dv",
"rows", "0"),
"//lst[@name='facet_ranges']/lst[@name='test_i_dv']/lst[@name='intervals']/int[@name='[0,2]'][.=3]");
{code}
this doesn't:
{code:java}
assertQ(req("q", "*:*", "facet", "true",
"facet.range", "{!facet.range.set='[0,2]'
facet.range.set='[3,10]'}test_i_dv",
"rows", "0"),
"//lst[@name='facet_ranges']/lst[@name='test_i_dv']/lst[@name='intervals']/int[@name='[0,2]'][.=3]",
"//lst[@name='facet_ranges']/lst[@name='test_i_dv']/lst[@name='intervals']/int[@name='[3,10]'][.=7]");
{code}
> Fold Interval Faceting into Range Faceting
> ------------------------------------------
>
> Key: SOLR-7795
> URL: https://issues.apache.org/jira/browse/SOLR-7795
> Project: Solr
> Issue Type: Task
> Reporter: Tomás Fernández Löbbe
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7795.patch, SOLR-7795.patch, SOLR-7795.patch,
> SOLR-7795.patch, SOLR-7795.patch
>
>
> Now that range faceting supports a "filter" and a "dv" method, and that
> interval faceting is supported on fields with {{docValues=false}}, I think we
> should make it so that interval faceting is just a different way of
> specifying ranges in range faceting, allowing users to indicate specific
> ranges.
> I propose we use the same syntax for intervals, but under the "range"
> parameter family:
> {noformat}
> facet.range=price&
> f.price.facet.range.set=[0,10]&
> f.price.facet.range.set=(10,100]
> {noformat}
> The counts for those ranges would come in the response also inside of the
> "range_facets" section. I'm not sure if it's better to include the ranges in
> the "counts" section, or in a different section (intervals?sets?buckets?).
> I'm open to suggestions.
> {code}
> "facet_ranges":{
> "price":{
> "counts":[
> "[0,10]",3,
> "(10,100]",2]
> }
> }
> {code}
> or…
> {code}
> "facet_ranges":{
> "price":{
> "intervals":[
> "[0,10]",3,
> "(10,100]",2]
> }
> }
> {code}
> We should support people specifying both things on the same field.
> Once this is done, "interval faceting" could be deprecated, as all it's
> functionality is now possible through range queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
