JSON Facet & Analytics API in Solr 5.1

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

JSON Facet & Analytics API in Solr 5.1

Yonik Seeley
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
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Yonik Seeley
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Erick Erickson
Personally I find the second form easier to read. The second level of
nesting in the first example confuses me at first glance.

I don't have a really strong preference here, but I vote for the second form.



On Fri, Apr 17, 2015 at 9:20 AM, Yonik Seeley <[hidden email]> wrote:

> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Mike Murphy
In reply to this post by Yonik Seeley
I like the first way.  It matches how elasticsearch does it
http://www.elastic.co/guide/en/elasticsearch/reference/1.x/search-aggregations-bucket-range-aggregation.html

Can we specify explicit ranges in Solr now like we can in elasticsearch?

I do like how Solr's version of aggs can be much shorter though!

elasticsearch :

{
    "aggs" : {
        "min_price" : { "min" : { "field" : "price" } }
    }
}

solr :

{
    facet : { min_price : "min(price)"  }
}

Great work!

On Fri, Apr 17, 2015 at 12:20 PM, Yonik Seeley <[hidden email]> wrote:

> 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 <[hidden email]> 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


--Mike
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Jean-Sebastien Vachon-3
In reply to this post by Yonik Seeley
I prefer the second way. I find it more readable and shorter.

Thanks for making Solr even better ;)

________________________________________
From: Yonik Seeley <[hidden email]>
Sent: Friday, April 17, 2015 12:20 PM
To: [hidden email]
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Trey Grainger
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 <
[hidden email]> wrote:

> I prefer the second way. I find it more readable and shorter.
>
> Thanks for making Solr even better ;)
>
> ________________________________________
> From: Yonik Seeley <[hidden email]>
> Sent: Friday, April 17, 2015 12:20 PM
> To: [hidden email]
> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Otis Gospodnetić
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 <[hidden email]> 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 <
> [hidden email]> wrote:
>
> > I prefer the second way. I find it more readable and shorter.
> >
> > Thanks for making Solr even better ;)
> >
> > ________________________________________
> > From: Yonik Seeley <[hidden email]>
> > Sent: Friday, April 17, 2015 12:20 PM
> > To: [hidden email]
> > 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Yonik Seeley
Thank you everyone for the feedback!

I've implemented and committed the flatter structure:
https://issues.apache.org/jira/browse/SOLR-7422
So either form can now be used (and I'll be switching to the flatter
method for examples when it actually reduces the levels).

For those who want to try it out, I just made a 5.2-dev snapshot:
https://github.com/yonik/lucene-solr/releases

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Yonik Seeley
Alther minor benefit to the flatter structure means that the "smart
merging" of multiple JSON parameters works a little better in
conjunction with facets.

For example, if you already had a "top_genre" facet, you could insert
a "top_author" facet more easily:

json.facet.top_genre.facet.top_author={type:terms, field:author, limit:5}

(For anyone who doesn't know what "smart merging" is,  see
http://yonik.com/solr-json-request-api/ )

-Yonik


On Sat, Apr 18, 2015 at 11:36 AM, Yonik Seeley <[hidden email]> wrote:

> Thank you everyone for the feedback!
>
> I've implemented and committed the flatter structure:
> https://issues.apache.org/jira/browse/SOLR-7422
> So either form can now be used (and I'll be switching to the flatter
> method for examples when it actually reduces the levels).
>
> For those who want to try it out, I just made a 5.2-dev snapshot:
> https://github.com/yonik/lucene-solr/releases
>
> -Yonik
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Lukáš Vlček
Late here but let me add one more thing: IIRC the recommendation for JSON
is to never use data as a key in objects. One of the benefits of not using
data as a keys in JSON is easier validation using JSON schema. If one wants
to validate JSON query for Elasticsearch today it is necessary to implement
custom parser (and grammar first of course).

Lukas

On Sat, Apr 18, 2015 at 11:46 PM, Yonik Seeley <[hidden email]> wrote:

> Alther minor benefit to the flatter structure means that the "smart
> merging" of multiple JSON parameters works a little better in
> conjunction with facets.
>
> For example, if you already had a "top_genre" facet, you could insert
> a "top_author" facet more easily:
>
> json.facet.top_genre.facet.top_author={type:terms, field:author, limit:5}
>
> (For anyone who doesn't know what "smart merging" is,  see
> http://yonik.com/solr-json-request-api/ )
>
> -Yonik
>
>
> On Sat, Apr 18, 2015 at 11:36 AM, Yonik Seeley <[hidden email]> wrote:
> > Thank you everyone for the feedback!
> >
> > I've implemented and committed the flatter structure:
> > https://issues.apache.org/jira/browse/SOLR-7422
> > So either form can now be used (and I'll be switching to the flatter
> > method for examples when it actually reduces the levels).
> >
> > For those who want to try it out, I just made a 5.2-dev snapshot:
> > https://github.com/yonik/lucene-solr/releases
> >
> > -Yonik
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Lukáš Vlček
Oh... and btw, I think the readability of the JSON will be less and less
important going forward. Queries will grow in size anyway (due to nested
facets) and the ability to quickly validate the query using some parser
will be more useful and practical than relying on human eye doing the check
instead.

I assume that both the ES and Solr will end up having some higher level
language for people to express queries and facets/aggregations in readable
form (anyone remember SQL?) and this will be transformed to JSON (or other
native) format down the road. In my opinion the most important thing for
any non-trivial JSON based language format now is to make sure it is parser
friendly and grammars can be defined easily for it.

On Sun, Apr 19, 2015 at 8:09 AM, Lukáš Vlček <[hidden email]> wrote:

> Late here but let me add one more thing: IIRC the recommendation for JSON
> is to never use data as a key in objects. One of the benefits of not using
> data as a keys in JSON is easier validation using JSON schema. If one wants
> to validate JSON query for Elasticsearch today it is necessary to implement
> custom parser (and grammar first of course).
>
> Lukas
>
> On Sat, Apr 18, 2015 at 11:46 PM, Yonik Seeley <[hidden email]> wrote:
>
>> Alther minor benefit to the flatter structure means that the "smart
>> merging" of multiple JSON parameters works a little better in
>> conjunction with facets.
>>
>> For example, if you already had a "top_genre" facet, you could insert
>> a "top_author" facet more easily:
>>
>> json.facet.top_genre.facet.top_author={type:terms, field:author, limit:5}
>>
>> (For anyone who doesn't know what "smart merging" is,  see
>> http://yonik.com/solr-json-request-api/ )
>>
>> -Yonik
>>
>>
>> On Sat, Apr 18, 2015 at 11:36 AM, Yonik Seeley <[hidden email]> wrote:
>> > Thank you everyone for the feedback!
>> >
>> > I've implemented and committed the flatter structure:
>> > https://issues.apache.org/jira/browse/SOLR-7422
>> > So either form can now be used (and I'll be switching to the flatter
>> > method for examples when it actually reduces the levels).
>> >
>> > For those who want to try it out, I just made a 5.2-dev snapshot:
>> > https://github.com/yonik/lucene-solr/releases
>> >
>> > -Yonik
>>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: JSON Facet & Analytics API in Solr 5.1

Davis, Daniel (NIH/NLM) [C]
In reply to this post by Otis Gospodnetić
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:[hidden email]]
Sent: Friday, April 17, 2015 11:16 PM
To: [hidden email]
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 <[hidden email]> 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 <
> [hidden email]> wrote:
>
> > I prefer the second way. I find it more readable and shorter.
> >
> > Thanks for making Solr even better ;)
> >
> > ________________________________________
> > From: Yonik Seeley <[hidden email]>
> > Sent: Friday, April 17, 2015 12:20 PM
> > To: [hidden email]
> > 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Frank li
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] <
[hidden email]> 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:[hidden email]]
> Sent: Friday, April 17, 2015 11:16 PM
> To: [hidden email]
> 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 <[hidden email]> 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 <
> > [hidden email]> wrote:
> >
> > > I prefer the second way. I find it more readable and shorter.
> > >
> > > Thanks for making Solr even better ;)
> > >
> > > ________________________________________
> > > From: Yonik Seeley <[hidden email]>
> > > Sent: Friday, April 17, 2015 12:20 PM
> > > To: [hidden email]
> > > 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 <[hidden email]>
> 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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Yonik Seeley
On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:

> 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?

What problems do you encounter when you try that?

If you try that URL with curl, be aware that curly braces {} are
special globbing characters in curl.  Turn them off with the "-g"
option:

curl -g "http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}"

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Frank li
This one does not have problem, but how do I include "sort" in this facet
query. Basically, I want to write a solr query which can sort the facet
count ascending. Something like "http://localhost:8983/solr
/demo/query?q=apple&json.facet={field=price sort='count asc'}
<http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>

I really appreciate your help.

Frank

<http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>

On Thu, May 7, 2015 at 2:24 PM, Yonik Seeley <[hidden email]> wrote:

> On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:
> > 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?
>
> What problems do you encounter when you try that?
>
> If you try that URL with curl, be aware that curly braces {} are
> special globbing characters in curl.  Turn them off with the "-g"
> option:
>
> curl -g "
> http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}"
>
> -Yonik
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Frank li
Is there any book to read so I won't ask such dummy questions? Thanks.

On Thu, May 7, 2015 at 2:32 PM, Frank li <[hidden email]> wrote:

> This one does not have problem, but how do I include "sort" in this facet
> query. Basically, I want to write a solr query which can sort the facet
> count ascending. Something like "http://localhost:8983/solr
> /demo/query?q=apple&json.facet={field=price sort='count asc'}
> <http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>
>
> I really appreciate your help.
>
> Frank
>
>
> <http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>
>
> On Thu, May 7, 2015 at 2:24 PM, Yonik Seeley <[hidden email]> wrote:
>
>> On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:
>> > 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?
>>
>> What problems do you encounter when you try that?
>>
>> If you try that URL with curl, be aware that curly braces {} are
>> special globbing characters in curl.  Turn them off with the "-g"
>> option:
>>
>> curl -g "
>> http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}
>> "
>>
>> -Yonik
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Frank li
Hi Yonik,

Any update for the question?

Thanks in advance,

Frank

On Thu, May 7, 2015 at 2:49 PM, Frank li <[hidden email]> wrote:

> Is there any book to read so I won't ask such dummy questions? Thanks.
>
> On Thu, May 7, 2015 at 2:32 PM, Frank li <[hidden email]> wrote:
>
>> This one does not have problem, but how do I include "sort" in this facet
>> query. Basically, I want to write a solr query which can sort the facet
>> count ascending. Something like "http://localhost:8983/solr
>> /demo/query?q=apple&json.facet={field=price sort='count asc'}
>> <http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>
>>
>> I really appreciate your help.
>>
>> Frank
>>
>>
>> <http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>
>>
>> On Thu, May 7, 2015 at 2:24 PM, Yonik Seeley <[hidden email]> wrote:
>>
>>> On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:
>>> > 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?
>>>
>>> What problems do you encounter when you try that?
>>>
>>> If you try that URL with curl, be aware that curly braces {} are
>>> special globbing characters in curl.  Turn them off with the "-g"
>>> option:
>>>
>>> curl -g "
>>> http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}
>>> "
>>>
>>> -Yonik
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Yonik Seeley
In reply to this post by Frank li
curl -g "http://localhost:8983/solr/techproducts/query?q=*:*&json.facet={cats:{terms:{field:cat,sort:'count+asc'}}}"

Using curl with everything in the URL is definitely trickier.
Everything needs to be URL escaped.  If it's not, curl will often
silently do nothing.
For example, when I had sort:'count asc' , the command above would do
nothing.  When I remembered to URL encode the space as a "+", it
started working.

It's definitely easier to use "-d" with curl...

curl  "http://localhost:8983/solr/techproducts/query" -d
'q=*:*&json.facet={cats:{terms:{field:cat,sort:"count asc"}}}'

That also allows you to format it nicer for reading as well:

curl  "http://localhost:8983/solr/techproducts/query" -d 'q=*:*&json.facet=
{cats:{terms:{
  field:cat,
  sort:"count asc"
}}}'

-Yonik


On Thu, May 7, 2015 at 5:32 PM, Frank li <[hidden email]> wrote:

> This one does not have problem, but how do I include "sort" in this facet
> query. Basically, I want to write a solr query which can sort the facet
> count ascending. Something like "http://localhost:8983/solr
> /demo/query?q=apple&json.facet={field=price sort='count asc'}
> <http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>
>
> I really appreciate your help.
>
> Frank
>
> <http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D>
>
> On Thu, May 7, 2015 at 2:24 PM, Yonik Seeley <[hidden email]> wrote:
>
>> On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:
>> > 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?
>>
>> What problems do you encounter when you try that?
>>
>> If you try that URL with curl, be aware that curly braces {} are
>> special globbing characters in curl.  Turn them off with the "-g"
>> option:
>>
>> curl -g "
>> http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}"
>>
>> -Yonik
>>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Frank li
Thank you, Yonik!

Looks cool to me. Only problem is it is not working for me.
I see you have "cats" and "cat" in your URL. "cat" must be a field name.
What is "cats"?

We are doing a POC with facet count ascending. You help is really important
to us.



On Sat, May 9, 2015 at 8:05 AM, Yonik Seeley <[hidden email]> wrote:

> curl -g "
> http://localhost:8983/solr/techproducts/query?q=*:*&json.facet={cats:{terms:{field:cat,sort:'count+asc'}}}
> "
>
> Using curl with everything in the URL is definitely trickier.
> Everything needs to be URL escaped.  If it's not, curl will often
> silently do nothing.
> For example, when I had sort:'count asc' , the command above would do
> nothing.  When I remembered to URL encode the space as a "+", it
> started working.
>
> It's definitely easier to use "-d" with curl...
>
> curl  "http://localhost:8983/solr/techproducts/query" -d
> 'q=*:*&json.facet={cats:{terms:{field:cat,sort:"count asc"}}}'
>
> That also allows you to format it nicer for reading as well:
>
> curl  "http://localhost:8983/solr/techproducts/query" -d
> 'q=*:*&json.facet=
> {cats:{terms:{
>   field:cat,
>   sort:"count asc"
> }}}'
>
> -Yonik
>
>
> On Thu, May 7, 2015 at 5:32 PM, Frank li <[hidden email]> wrote:
> > This one does not have problem, but how do I include "sort" in this facet
> > query. Basically, I want to write a solr query which can sort the facet
> > count ascending. Something like "http://localhost:8983/solr
> > /demo/query?q=apple&json.facet={field=price sort='count asc'}
> > <
> http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D
> >
> >
> > I really appreciate your help.
> >
> > Frank
> >
> > <
> http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D
> >
> >
> > On Thu, May 7, 2015 at 2:24 PM, Yonik Seeley <[hidden email]> wrote:
> >
> >> On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:
> >> > 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?
> >>
> >> What problems do you encounter when you try that?
> >>
> >> If you try that URL with curl, be aware that curly braces {} are
> >> special globbing characters in curl.  Turn them off with the "-g"
> >> option:
> >>
> >> curl -g "
> >>
> http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}"
> >>
> >> -Yonik
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: JSON Facet & Analytics API in Solr 5.1

Frank li
Here is our SOLR query:

http://qa-solr:8080/solr/select?q=type:PortalCase&json.facet={categories:{terms:{field:campaign_id_ls,sort:%27count+asc%27}}}&rows=0

I replaced "cats" with "categories". It is still not working.

On Sun, May 10, 2015 at 12:10 AM, Frank li <[hidden email]> wrote:

> Thank you, Yonik!
>
> Looks cool to me. Only problem is it is not working for me.
> I see you have "cats" and "cat" in your URL. "cat" must be a field name.
> What is "cats"?
>
> We are doing a POC with facet count ascending. You help is really
> important to us.
>
>
>
> On Sat, May 9, 2015 at 8:05 AM, Yonik Seeley <[hidden email]> wrote:
>
>> curl -g "
>> http://localhost:8983/solr/techproducts/query?q=*:*&json.facet={cats:{terms:{field:cat,sort:'count+asc'}}}
>> <http://localhost:8983/solr/techproducts/query?q=*:*&json.facet=%7Bcats:%7Bterms:%7Bfield:cat,sort:'count+asc'%7D%7D%7D>
>> "
>>
>> Using curl with everything in the URL is definitely trickier.
>> Everything needs to be URL escaped.  If it's not, curl will often
>> silently do nothing.
>> For example, when I had sort:'count asc' , the command above would do
>> nothing.  When I remembered to URL encode the space as a "+", it
>> started working.
>>
>> It's definitely easier to use "-d" with curl...
>>
>> curl  "http://localhost:8983/solr/techproducts/query" -d
>> 'q=*:*&json.facet={cats:{terms:{field:cat,sort:"count asc"}}}'
>>
>> That also allows you to format it nicer for reading as well:
>>
>> curl  "http://localhost:8983/solr/techproducts/query" -d
>> 'q=*:*&json.facet=
>> {cats:{terms:{
>>   field:cat,
>>   sort:"count asc"
>> }}}'
>>
>> -Yonik
>>
>>
>> On Thu, May 7, 2015 at 5:32 PM, Frank li <[hidden email]> wrote:
>> > This one does not have problem, but how do I include "sort" in this
>> facet
>> > query. Basically, I want to write a solr query which can sort the facet
>> > count ascending. Something like "http://localhost:8983/solr
>> > /demo/query?q=apple&json.facet={field=price sort='count asc'}
>> > <
>> http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D
>> >
>> >
>> > I really appreciate your help.
>> >
>> > Frank
>> >
>> > <
>> http://localhost:8983/solr/demo/query?q=apple&json.facet=%7Bx:%27avg%28price%29%27%7D
>> >
>> >
>> > On Thu, May 7, 2015 at 2:24 PM, Yonik Seeley <[hidden email]> wrote:
>> >
>> >> On Thu, May 7, 2015 at 4:47 PM, Frank li <[hidden email]> wrote:
>> >> > 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?
>> >>
>> >> What problems do you encounter when you try that?
>> >>
>> >> If you try that URL with curl, be aware that curly braces {} are
>> >> special globbing characters in curl.  Turn them off with the "-g"
>> >> option:
>> >>
>> >> curl -g "
>> >>
>> http://localhost:8983/solr/demo/query?q=apple&json.facet={x:'avg(price)'}
>> "
>> >>
>> >> -Yonik
>> >>
>>
>
>
12