lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank li <fudon...@gmail.com>
Subject Re: JSON Facet & Analytics API in Solr 5.1
Date Thu, 07 May 2015 20:47:57 GMT
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.davis@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.gospodnetic@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 <solrtrey@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.vachon@wantedanalytics.com> wrote:
> >
> > > I prefer the second way. I find it more readable and shorter.
> > >
> > > Thanks for making Solr even better ;)
> > >
> > > ________________________________________
> > > From: Yonik Seeley <yseeley@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 <yseeley@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message