Обсуждение: Why is it "JSQuery"?
Oleg, Teodor, and Hackers: Love what you’re doing with JSQuery. I’m curious, though, whether you considered adopting an existing syntax, such as JSONPath. http://goessner.net/articles/JsonPath/ Might be easier for people to pick up and use. Thoughts? Best, David
On 06/05/2014 08:08 PM, David E. Wheeler wrote: > Oleg, Teodor, and Hackers: > > Love what you’re doing with JSQuery. I’m curious, though, whether you considered adopting an existing syntax, such as JSONPath. > > http://goessner.net/articles/JsonPath/ > > Might be easier for people to pick up and use. Thoughts? My understanding is that it's meant to be analogous to tsquery. At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be. cheers andrew
On Jun 5, 2014, at 5:25 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > My understanding is that it's meant to be analogous to tsquery. > > At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive thanI gather JSQuery is meant to be. Yes, but perhaps it could be a superset. I guess my real question is: Should it not be based on some existing dialect, preferably something in fairly wide use outsidethe Postgres community? Unless that something is awful, of course. David
Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts. On Fri, Jun 6, 2014 at 4:34 AM, David E. Wheeler <david@justatheory.com> wrote: > On Jun 5, 2014, at 5:25 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > >> My understanding is that it's meant to be analogous to tsquery. >> >> At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive thanI gather JSQuery is meant to be. > > Yes, but perhaps it could be a superset. > > I guess my real question is: Should it not be based on some existing dialect, preferably something in fairly wide use outsidethe Postgres community? > > Unless that something is awful, of course. > > David >
On Jun 6, 2014, at 6:54 AM, Oleg Bartunov <obartunov@gmail.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 ifwe 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! * [UNQL](http://www.unqlspec.org/): Too similar to SQL * [JAQL](https://code.google.com/p/jaql/): Too different from SQL * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose * [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, shouldinspire the JSQuery syntax, and there should be reasons why and why not. 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. Best, David
On 06/06/2014 09:12 AM, David E. Wheeler wrote: > On Jun 6, 2014, at 6:54 AM, Oleg Bartunov <obartunov@gmail.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*, butif 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, shouldinspire 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
On Jun 6, 2014, at 12:51 PM, Josh Berkus <josh@agliodbs.com> wrote: >> * [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. I had enough people complain about Test::XPath, which tests the structure of XML and HTML documents using XPath. They didn'tlike how verbose XPath was, preferring CSS selectors. So I ended up with a patch to support CSS syntax, too. CSS-stylesyntax is part of what people like about JQuery, too. > 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? I think there is JQuery, JSONPath, and everything else, really. If we can draw some parallels, I think that would be sufficientto make people comfortable. >> 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? It’s Google. You really want to wrangle with their attorneys? David
On 06/06/2014 03:23 PM, David E. Wheeler wrote: > On Jun 6, 2014, at 12:51 PM, Josh Berkus <josh@agliodbs.com> wrote: >> 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? > > I think there is JQuery, JSONPath, and everything else, really. If we can draw some parallels, I think that would be sufficientto make people comfortable. Well, then those are the only ones worth considering. >>> 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? > > It’s Google. You really want to wrangle with their attorneys? Google is not going to sue us over a minor OSS project which isn't a commercial product. The relevant question is: are users liable to confuse our jsquery with Google jsquery? Maybe we should call it "jsonesque" ;-) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Jun 6, 2014, at 3:50 PM, Josh Berkus <josh@agliodbs.com> wrote: > Maybe we should call it "jsonesque" ;-) I propose JOQL: JSON Object Query Language. Best, David PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/).
People, we have many other tasks than guessing the language name. jsquery is just an extension, which we invent to test our indexing stuff. Eventually, it grew out. I think we'll think on better name if developers agree to have it in core. For now, jsquery is good enough to us. jsquery name doesn't need to be used at all, by the way. Oleg On Tue, Jun 10, 2014 at 10:04 PM, David E. Wheeler <david@justatheory.com> wrote: > On Jun 6, 2014, at 3:50 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> Maybe we should call it "jsonesque" ;-) > > I propose JOQL: JSON Object Query Language. > > Best, > > David > > PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/).
The closest problem we have is jsonb statistics (lack of, actually) , which prevents use of all the power of jsquery. I hope Jan Urbański could work on this. Oleg On Tue, Jun 10, 2014 at 11:06 PM, Oleg Bartunov <obartunov@gmail.com> wrote: > People, > > we have many other tasks than guessing the language name. > jsquery is just an extension, which we invent to test our indexing > stuff. Eventually, it grew out. I think we'll think on better name > if developers agree to have it in core. For now, jsquery is good > enough to us. > > jsquery name doesn't need to be used at all, by the way. > > Oleg > > On Tue, Jun 10, 2014 at 10:04 PM, David E. Wheeler > <david@justatheory.com> wrote: >> On Jun 6, 2014, at 3:50 PM, Josh Berkus <josh@agliodbs.com> wrote: >> >>> Maybe we should call it "jsonesque" ;-) >> >> I propose JOQL: JSON Object Query Language. >> >> Best, >> >> David >> >> PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/).
On Jun 10, 2014, at 12:06 PM, Oleg Bartunov <obartunov@gmail.com> wrote: > we have many other tasks than guessing the language name. > jsquery is just an extension, which we invent to test our indexing > stuff. Eventually, it grew out. I think we'll think on better name > if developers agree to have it in core. For now, jsquery is good > enough to us. > > jsquery name doesn't need to be used at all, by the way. Yeah, I was more on about syntax than the name. We can change that any time before you release it. David
On 06/10/2014 02:46 PM, David E. Wheeler wrote: > On Jun 10, 2014, at 12:06 PM, Oleg Bartunov <obartunov@gmail.com> wrote: > >> we have many other tasks than guessing the language name. >> jsquery is just an extension, which we invent to test our indexing >> stuff. Eventually, it grew out. I think we'll think on better name >> if developers agree to have it in core. For now, jsquery is good >> enough to us. >> >> jsquery name doesn't need to be used at all, by the way. > > Yeah, I was more on about syntax than the name. We can change that any time before you release it. I've been poking at the various json-query syntaxes you forwarded, and none of them really work for the actual jsquery features. Also, the existing syntax has the advantage of being *simple*, relatively speaking, and reasonably similar to JSONPATH. In other words, what I'm saying is: I don't think there's an existing, poplular syntax we could reasonably use. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 06/15/2014 04:58 PM, Josh Berkus wrote: > I've been poking at the various json-query syntaxes you forwarded, and > none of them really work for the actual jsquery features. Also, the > existing syntax has the advantage of being *simple*, relatively > speaking, and reasonably similar to JSONPATH. > > In other words, what I'm saying is: I don't think there's an existing, > poplular syntax we could reasonably use. > Not to mention the similarity to tsquery, which is something not to be despised. cheers andrew
On Jun 15, 2014, at 1:58 PM, Josh Berkus <josh@agliodbs.com> wrote: > In other words, what I'm saying is: I don't think there's an existing, > poplular syntax we could reasonably use. Okay, I’m good with that. Would be handy to document it in such a way as to kind of put it forward as a standard. :-) D