Re: Why is it "JSQuery"?

On 06/06/2014 09:12 AM, David E. Wheeler wrote:
> On Jun 6, 2014, at 6:54 AM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
>
>> Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.
>
> Sure, but could we not potentially build on its syntax, instead of building a new one? I’m not saying we *should*, but if we don’t, I think there should be a discussion about why not. For example, I think it would not be a good idea to follow [JSONiq](http://www.jsoniq.org/) because who wants to write queries in JSON? (Have we learned nothing from XSLT?).
>
> Here’s a (partial) list of existing JSON query languages:
>
> http://stackoverflow.com/a/7812073/79202
>
> The arguments might be:
>
> * [JSONiq](http://jsoniq.org/): Queries in JSON? Gross!

Also overly complex for the functionality we support. There's also no
way to make the jsquery strings valid JSON without adding a bunch of
extra text.

> * [UNQL](http://www.unqlspec.org/): Too similar to SQL

... also intended to be a *complete* replacement for SQL, whereas we
just want a syntax to search JSON fields.

> * [JAQL](https://code.google.com/p/jaql/): Too different from SQL
> * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose

I don't agree with the too verbose, but lacking AND|OR is pretty crippling.

> * [JSON Query](https://github.com/mmckegg/json-query): Too little there
> * [Mongo](http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON): Gross syntax
> * [LINQ](http://james.newtonking.com/archive/2008/03/02/json-net-2-0-beta-2): Too similar to SQL
> * [searchjs](https://github.com/deitch/searchjs): Queries in JSON? Gross!
> * [JQuery](http://jquery.org/): It's for HTML, not JSON
> * [SpahQL](http://danski.github.io/spahql/): More like XPath
> * [ObjectPath](http://adriank.github.io/ObjectPath/): Too verbose
> * [JFunk](https://code.google.com/p/jfunk/): XPathy
> * [JData](http://jaydata.org): Queries in JavaScript? C’mon.
>
> These are just off-the-cuff evaluations in 10 minutes of looking -- surely not all of them are accurate. Some of them maybe *are* useful to emulate. It’s definitely worthwhile, IMHO, to evaluate prior art and decide what, if any of it, should inspire the JSQuery syntax, and there should be reasons why and why not.

Well, I'd also say that we don't care about syntaxes which are not
already popular. There's no point in being compatible with something
nobody uses. How many of the above have any uptake?

Also, the explosion of query languages in this area is not an
encouraging sign for us being able to pick the "right" one. UUID-OSSP
anyone?

So the advantage of the current "jsquery" syntax is that it's similar to
tsquery, which already has some adoption in our userbase. On the other
hand, I'm not sure how many people actually understand the tsquery
syntax, and jsquery will be different enough to trip people up.

> I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing.

I saw that too, but I don't get the impression that Google jsquery is
all that active. No?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com