Nice, Yonik!
Here is one suggestion. OK, I'm beginning you - pleeeeeeeeease don't make
it be as hard on the eyes as Local Params. :)  I thought it was just me who
could never get along with Local Params, but I've learned that a number of
people find Local Params very hard to grok.  Yes, this is JSON, so right
there it may be better, but for instance I see "v" here which to a regular
human may not be as nice as "value" if that is what "v" stands for.
Looking at examples from the JIRA issue....

{'frange':{'v':'mul(foo_i,2)', 'l':20,'u':24}}}


v is value?

mul is multiply?

what's "l"? left? No, low(er)?

what's "u"? Aha, upper?


I'd rather use a few extra character and be clear, easily memorable, and
user friendly.  People love ES's JSON API and I have never ever heard
anyone say it's too verbose.

Thanks,
Otis





On Thu, Jan 24, 2013 at 8:44 PM, Yonik Seeley <yo...@lucidworks.com> wrote:

> Although "lucene" syntax tends to be quite concise, nice looking, and
> easy to build by hand (the web browser is a major debugging tool for
> me), some people prefer to use a more "structured" query language
> that's easier to build up programmatically.  XML fits the bill, but
> people tend to prefer JSON these days.
>
> Hence my first quick prototype:
> https://issues.apache.org/jira/browse/SOLR-4351
>
> I'm pretty happy so far with how easily it's fit in with our QParser
> framework, which should generally allow parsers to not care about the
> underlying syntax of queries they need to deal with.
> For example: the "join" qparser uses the query specified by "v", but
> doesn't care of it's in lucene syntax, or if it was part of the JSON.
>
> {'join':{'from':'qqq_s', 'to':'www_s', 'v':'id:10'}}
> {'join':{'from':'qqq_s', 'to':'www_s', 'v':{'term':{'id':'10'}}}}
>
> Note: replace the single quotes with double quotes before trying it
> out - these are just test strings that have the replacement done in
> the test code so that they are easier to read.
>
> There's a fair bit left to do of course... like how to deal with
> "boost", "cache", "cost", parameter dereferencing, etc.
> Feedback welcome... and hopefully this will be good to go for 4.2
>
> -Yonik
> http://lucidworks.com
>

Reply via email to