Agreed, I also prefer the second way. I find it more readible, less verbose
while communicating the same information, less confusing to mentally parse
("is 'terms' the name of my facet, or the type of my facet?..."), and less
prone to syntactlcally valid, but logically invalid inputs. Let's break
those topics down.
*1) Less verbose while communicating the same information:*
The flatter structure is particularly useful when you have nested facets to
reduce unnecessary verbosity / extra levels. Let's contrast the two
approaches with just 2 levels of subfacets:
** Current Format **
top_genres:{
terms:{
field: genre,
limit: 5,
facet:{
top_authors:{
terms:{
field: author,
limit: 4,
facet: {
top_books:{
terms:{
field: title,
limit: 5
}
}
}
}
}
}
}
}
** Flat Format **
top_genres:{
type: terms,
field: genre,
limit: 5,
facet:{
top_authors:{
type: terms
field: author,
limit: 4,
facet: {
top_books:{
type: terms
field: title,
limit: 5
}
}
}
}
}
The flat format is clearly shorter and more succinct, while communicating
the same information. What value do the extra levels add?
*2) Less confusing to mentally parse*
I also find the flatter structure less confusing, as I'm consistently
having to take a mental pause with the current format to verify whether
"terms" is the name of my facet or the type of my facet and have to count
the curly braces to figure this out. Not that I would name my facets like
this, but to give an extreme example of why that extra mental calculation
is necessary due to the name of an attribute in the structure being able to
represent both a facet name and facet type:
terms: {
terms: {
field: genre,
limit: 5,
facet: {
terms: {
terms:{
field: author
limit: 4
}
}
}
}
}
In this example, the first "terms" is a facet name, the second "terms" is a
facet type, the third is a facet name, etc. Even if you don't name your
facets like this, it still requires parsing someone else's query mentally
to ensure that's not what was done.
3) *Less prone to syntactically valid, but logically invalid inputs*
Also, given this first format (where the type is indicated by one of
several possible attributes: terms, range, etc.), what happens if I pass in
multiple of the valid JSON attributes... the flatter structure prevents
this from being possible (which is a good thing!):
top_authors : {
terms : {
field : author,
limit : 5
},
range : {
field : price,
start : 0,
end : 100,
gap : 20
}
}
I don't think the response format can currently handle this without adding
in extra levels to make it look like the input side, so this is an
exception case even thought it seems syntactically valid.
So in conclusion, I'd give a strong vote to the flatter structure. Can
someone enumerate the benefits of the current format over the flatter
structure (I'm probably dense and just failing to see them currently)?
Thanks,
-Trey
On Fri, Apr 17, 2015 at 2:28 PM, Jean-Sebastien Vachon <
jean-sebastien.vac...@wantedanalytics.com> wrote:
> I prefer the second way. I find it more readable and shorter.
>
> Thanks for making Solr even better ;)
>
> ________________________________________
> From: Yonik Seeley <ysee...@gmail.com>
> Sent: Friday, April 17, 2015 12:20 PM
> To: solr-user@lucene.apache.org
> Subject: Re: JSON Facet & Analytics API in Solr 5.1
>
> Does anyone have any thoughts on the current general structure of JSON
> facets?
> The current general form of a facet command is:
>
> <facet_name> : { <facet_type> : <facet_args> }
>
> For example:
>
> top_authors : { terms : {
> field : author,
> limit : 5,
> }}
>
> One alternative I considered in the past is having the type in the args:
>
> top_authors : {
> type : terms,
> field : author,
> limit : 5
> }
>
> It's a flatter structure... probably better in some ways, but worse in
> other ways.
> Thoughts / preferences?
>
> -Yonik
>
>
> On Tue, Apr 14, 2015 at 4:30 PM, Yonik Seeley <ysee...@gmail.com> wrote:
> > Folks, there's a new JSON Facet API in the just released Solr 5.1
> > (actually, a new facet module under the covers too).
> >
> > It's marked as experimental so we have time to change the API based on
> > your feedback. So let us know what you like, what you would change,
> > what's missing, or any other ideas you may have!
> >
> > I've just started the documentation for the reference guide (on our
> > confluence wiki), so for now the best doc is on my blog:
> >
> > http://yonik.com/json-facet-api/
> > http://yonik.com/solr-facet-functions/
> > http://yonik.com/solr-subfacets/
> >
> > I'll also be hanging out more on the #solr-dev IRC channel on freenode
> > if you want to hit me up there about any development ideas.
> >
> > -Yonik
>
