Hi Yonik, I am reading your blog. It is helpful. One question for you, for following example,
curl http://localhost:8983/solr/query -d 'q=*:*&rows=0& json.facet={ categories:{ type : terms, field : cat, sort : { x : desc}, facet:{ x : "avg(price)", y : "sum(price)" } } } ' If I want to write it in the format of this: http://localhost:8983/solr/query?q=apple&json.facet={x:'avg(campaign_ult_defendant_cnt_is)'}, how do I do? Thanks, Frank On Mon, Apr 20, 2015 at 7:35 AM, Davis, Daniel (NIH/NLM) [C] < daniel.da...@nih.gov> wrote: > 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 > > > > > >
