Indeed - XML is not "human readable" if it contains colons, JSON is not "human readable" if it is too deep, and the objects/keys are not semantic. I also vote for flatter.
-----Original Message----- From: Otis Gospodnetic [mailto:otis.gospodne...@gmail.com] Sent: Friday, April 17, 2015 11:16 PM To: solr-user@lucene.apache.org Subject: Re: JSON Facet & Analytics API in Solr 5.1 Flatter please. The other nested stuff makes my head hurt. Until recently I thought I was the only person on the planet who had a hard time mentally parsing anything but the simplest JSON, but then I learned that I'm not alone at all.... it's just that nobody is saying it. :) Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/ On Fri, Apr 17, 2015 at 7:26 PM, Trey Grainger <solrt...@gmail.com> wrote: > 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 > > >
