[
https://issues.apache.org/jira/browse/SOLR-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996167#comment-12996167
]
Hoss Man commented on SOLR-1240:
--------------------------------
bq. I think we should let it be known that "facet.date" is deprecated in 3.1.
That way it can be removed in a future release without waiting yet another
release.
good catch ... i thought i had done that....
Committed revision 1071842. - trunk
Committed revision 1071843. - 3x
...i'll also add a note to the wiki
bq. I think it's very odd that the default for the include parameter is for
both edges to be inclusive. This means double-counting! Yes, that's how it used
to work, but I argue it never should have worked that way and I don't think
anyone is actually depending on this behavior. So backwards-compatibility is
moot. I propose "lower" be the default.
Hmmm... i think i disagree with you there ... in no particular order...
* including both edges is the most common convention used for range queries
(ie: {code}foo:[5 TO 10]{code} so i think it makes sense for the gap ranges
generated by range faceting to be consistent by default.
* I don't really feel like there is any compelling reason why "lower" would
make a better default then "upper" or "lower,edge" or "upper,edge", etc... in
all of those cases there wouldn't be double counting, and equally valid
arguments could be made for all of them -- but ultimately it would come down to
specific use cases.
* the current default -- while certainly not ideal, is at least consistent with
some other things for people who are already familiar with them (ie: legacy
date faceting, and my first point about common use of range queries above)
* it's soooooooo easy for people to set their own default facet.range.include
to whatever they want, i really don't see much harm in the current one.
Ultimately: double counting may be something silly and legacy, but it's easy to
change and none of the other options would make indisputably better defaults,
so why not at least be consistent with our silly legacy?
(anybody else have an opinion? I've got no qualms about changing my mind if i'm
in the minority here)
> Numerical Range faceting
> ------------------------
>
> Key: SOLR-1240
> URL: https://issues.apache.org/jira/browse/SOLR-1240
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Gijs Kunze
> Assignee: Hoss Man
> Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch,
> SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch,
> SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.use-nl.patch
>
>
> For faceting numerical ranges using many facet.query query arguments leads to
> unmanageably large queries as the fields you facet over increase. Adding the
> same faceting parameter for numbers which already exists for dates should fix
> this.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
