[
https://issues.apache.org/jira/browse/SOLR-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156425#comment-13156425
]
Hoss Man commented on SOLR-1351:
--------------------------------
Someone asked on the dev list about resurrecting Uri's patch...
reviewing it now, i suspect that getting it to apply to the trunk (to work as
Uri originally wrote it) would just be a simple matter of tweaking the paths
and line numbers to get it to apply cleanly.
There are a few other things that I think would need to be addressed before i'd
be comfortable committing however...
---
1) need to make sure range faceting is also supported
2) need a test to verify that things work as expected with distributed searches
-- some of the params (facet.limit, facet.mincount, facet.offset) have special
handling in FacetComponent that may need tweaked to work properly when they are
specified on a "key" instead of on a true field name.
3) need to make sure some precedence rules like those described in SOLR-2251
work, are tested, and documented. The main issue here is that if someone is
already using the "key" local param for the purposes of filter exclusion, the
precedence of per-field overrides on things like "facet.limit" should still
apply and not just be ignored because of "per-key" overrides.
ie: a request like this in Solr 3.4...
{code}facet.limit=10&facet.field=foo&facet.field={!key=bar
ex=dt}foo&f.foo.facet.limit=100{code}
...causes both of the facet results for field "foo" to get a limit of 100
overriding the "global" limit of 10 -- that shouldn't change when this feature
is added, and skimming Uri's original patch i'm pretty sure it would:
{{getFieldParams("bar","facet.limit")}} isn't going to pay any attention to
"f.foo.facet.limit" at all, would look for "f.bar.facet.limit" and if it's not
found then it would just use the value of "facet.limit"
---
#1 should be trivial, #2 is a big question mark: I have no idea if it will just
work as is or if some special logic needs to be added (and if so what). #3 is
probably going to be a little tricky just because it doesn't play nicely with
any of the logic in SolrParams aboout how per-field overrides should work, so
we may need a new method in SolrParams to deal with this, or maybe just make
SolrParams.fname() public so SimpleFacets can (cleanly) check the things it
wants to check directly with something like...
{code}
static String getKeyOrDefault(final String key, final String field,
final String param, final SolrParams params) {
String result = params.get(params.fname(key, param);
if (null == result) {
result = params.getFieldParam(field, param);
}
return result;
}
{code}
> facet on same field different ways
> ----------------------------------
>
> Key: SOLR-1351
> URL: https://issues.apache.org/jira/browse/SOLR-1351
> Project: Solr
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Fix For: 3.5, 4.0
>
> Attachments: SOLR-1351.patch
>
>
> There is a general need to facet on the same field in different ways
> (different prefixes, different filters). We need a way to express this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
