: facet.field=prac_spec_heir&facet.field=prac_spec_heir
...
: Thoughts? Seems like a new bug in 4.6 ?
Nope ... it's always been like that. We could concievably dedup, but
that seems like unneccessary cycles in most cases -- if the client asks
for redundent faceting, the client gets redundent faceting.
Even if someone proposed a patch to dedup as a way to "help" out wayward
users who specify redudent faceting by mistake, we'd have to think
reeaaaaaaly careful about how we go about it, since there are several
usecases where people can explicitly ask for "duplicate" faceting
(depending on your definition of "duplicate") to get different things...
* same raw field name, but diff options and diff output keys...
facet.field={!key=bar ex=ex1}xxx&facet.field={!key=foo ex=ex2}xxx
...basic dedup on the underlying field names would break this
* diff raw field names, but same output key so client can lump them
together...
facet.field={!key=foo ex=ex1}xxx&facet.field={!key=foo ex=ex2}yyy
...deduping on the output key would break this
: we get it twice in the results. This breaks deserialization on wt=json
: since you cannot have the same name twice....
as mentioned in another reply: this is completely valid and legal json --
it's just that some json parsers are broken (or have broken default
behavior).
-Hoss
http://www.lucidworks.com/
