Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMESPath – A query language for JSON

jmespath.org

Post reply on HN
Print view View original

81–90 of 131 posts

Re: JMESPath – A query language for JSON

#81

Post by ak217 »

johnhenry wrote: post #61

Besides's this projects cli, jp ( https://github.com/jmespath/jp ), I see jl ( https://github.com/chrisdone/jl ) and jq ( https://github.com/stedolan/jq/ ) in the comments. I wonder if anyone has had experience with all three (or even just one) and can comment on their experiences?

jq is by far the best developed and has the most intuitive syntax, but it doesn't have a formal spec for its language.

I have been maintaining https://github.com/kislyuk/yq, which wraps jq with a transcoder for YAML and XML.

Re: JMESPath – A query language for JSON

#82

Post by c-smile »

bufferoverflow wrote: post #15
xchaotic wrote: post #11

The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc

We still need XSLT for JSON to complete the circle. Though it seems like XSLT should support JSON: https://www.w3.org/TR/xslt-30/#json

There are plenty transformers already, for example: http://goessner.net/articles/jsont/

Re: JMESPath – A query language for JSON

#83

Post by lioeters »

xonix wrote: post #30

My tiny lib with very similar functionality: [1]. The query syntax is slightly different though. Also I decided to re-use JS for evaluation of sub-expressions instead of implementing own full-fledged parser. [1] https://github.com/xonixx/jsqry

I love libraries like this, which is small enough to be read in one sitting. I can scan through and get a general understanding of everything that it does.

The "evaluation of sub-expressions" made me curious. This line:

   token.func = Function('_,i,args', 'return ' + token.val);
..could be a potential security issue with user-submitted expressions?

Re: JMESPath – A query language for JSON

#84

Post by jelder »

Finnucane wrote: post #40
hliyan wrote: post #23

Earlier quoted context omitted.

Isn't that what we want? I would think that solving the same problems for a less verbose format is a good thing. And looking at the examples and the library support ( http://jmespath.org/libraries.html ) I would say this solves a real problem. I can already think of several use cases for my own system. The fact that a solution is treading familiar ground does not invalidate its utility.

It's not very much less verbose, really. You still need a key and a value. The only thing you lose, really, is the end tag. For a complex text document in say TEI or Docbook, I don't see how this is much of an advantage.

The reason I prefer JSON over XML is the latter's ambiguity. It's completely obvious how to convert a native object into a JSON object, for example. The translation to XML brings all sorts of questions about when to use tags vs. attributes of tags. It's cognitive load I'd rather spend on solving the problem at hand, not serialization.

If there had been an opinionated SGML syntax which mapped directly and unambiguously to common language primitives and back, I'm sure it would have been more popular than JSON.

Re: JMESPath – A query language for JSON

#85

Post by mjburgess »

danbruc wrote: post #73
spraak wrote: post #55

Earlier quoted context omitted.

What reasons did you not go with SQL itself? I may not fully understand what you're trying to do, but in any case it sounds really interesting.

I never tried it but I am expecting the performance to be not good enough, it takes already several minutes with code specifically written to perform the calculations I am interested in. And because I don't know what exactly I am looking for I need more or less interactive speed so that I can try out many different ways to look at the data. But maybe I could use [materialized] views to convey enough information to th…

100% you should.

All of what you have just described isnt very hard in SQL.. coalescing on null, aggregating, etc.

GROUPING SETS() will give you your missing rows.

Re: JMESPath – A query language for JSON

#86

Post by zephharben »

johnhenry wrote: post #61

Besides's this projects cli, jp ( https://github.com/jmespath/jp ), I see jl ( https://github.com/chrisdone/jl ) and jq ( https://github.com/stedolan/jq/ ) in the comments. I wonder if anyone has had experience with all three (or even just one) and can comment on their experiences?

I've used jq and jp/JMESPATH quite a bit.

I love jq, and use it more often than JMESPATH. However, recently I've noticed that I arrive at "the solution" I need more quickly with JMESPATH.

In retrospect, JMESPATH's documentation and examples have been more useful for me than jq's (docs/examples).

Re: JMESPath – A query language for JSON

#87

Post by steve_adams_86 »

chatmasta wrote: post #17
crooked-v wrote: post #5

The example on the front page seems equivalent to (and only marginally less verbose than): locations .filter(l => l.state === 'WA') .map(l => l.name) .sort() .join(', ')

The benefit of a query language is that it can be described declaratively (i.e. in a non-executable text file, perhaps within JSON itself), and then programs written in any language can execute its query logic using a standard interpreter written in that specific programming language. So you get reusability of queries across the stack, in all languages that implement a parser against the spec. Your example only provi…

I really appreciate this comment. I was trying to figure out why I wouldn't use native data types and functions, but this makes it clear.

In your opinion, where would someone be storing the json such that they'd benefit from a tool like this? The only time I use json outside of pulling it from an API (where I can convert it to a native object) is probably storing it in postgres, where I've already got json querying tools.

Re: JMESPath – A query language for JSON

#88

Post by avmich »

bufferoverflow wrote: post #15
xchaotic wrote: post #11

The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc

We still need XSLT for JSON to complete the circle. Though it seems like XSLT should support JSON: https://www.w3.org/TR/xslt-30/#json

XML Stylesheet Transformation, the language to describe transformations of XML documents into another XML documents. Isn't jq or JMESPath an example of such a language for transformations?

Re: JMESPath – A query language for JSON

#89

Post by fiatjaf »

johnhenry wrote: post #61

Besides's this projects cli, jp ( https://github.com/jmespath/jp ), I see jl ( https://github.com/chrisdone/jl ) and jq ( https://github.com/stedolan/jq/ ) in the comments. I wonder if anyone has had experience with all three (or even just one) and can comment on their experiences?

Apparently JMESPath is a better JSONPath/dot-notation alternative for querying JSON, while jq and jl are full-featured fully functional programming languages that happen to use JSON as their underlying data type.

I had never heard of jl before, but I've recently compiled an "awesome" collection of jq tools, libraries and use-cases at https://github.com/fiatjaf/awesome-jq that may be worth checking out.

Re: JMESPath – A query language for JSON

#90

Post by avmich »

foepys wrote: post #22
zoul wrote: post #19

Earlier quoted context omitted.

Is that a bad thing? For cases where the document is at least partially written by hand it makes sense to replace XML with something more friendly, such as JSON or YAML.

Wasn't the basic idea of JSON to be small and unstructured to be sent between applications? Shoehorning everything into JSON that is already solved by XML seems illogical, as GP already said. It reeks of NIH. People shouldn't use JSON for anything hand-written. YAML or even the older INI format are way better suited for configuration files for one reason alone: they allow comments.

To me, JSON can be viewed as slightly enhanced S-expressions, enhanced in a particular way. It would sound strange hearing "shoehorning everything into S-expressions in Lisp that is already solved by structural Fortran syntax seems illogical".

NIH claim is probably valid when there are no noticeable difference. In my opinion, XML differs a lot from JSON, particularly when one need to write snippets by hand. JSON also seems more logical/laconic (once upon a time M-expressions were supposed to come to stage, but S-expressions turned up to be good enough).

Post reply on HN