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

121–130 of 131 posts

Re: JMESPath – A query language for JSON

#121

Post by lox »

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.

Try implementing an xml parser sometime. The encoding and entity parsing alone is so complicated it’s brain melting. Compare that to the JSON spec and then ask why the world has decided JSON is the better format for casual object graph encoding. Not sure I could make the same argument about YAML though.

Re: JMESPath – A query language for JSON

#122

Post by Thiez »

avmich wrote: post #117
bshacklett wrote: post #109

Earlier quoted context omitted.

No, those are query languages akin to XPath.

What's the difference between query and transformation then? Isn't transformation a (vector) function ^f of input ^x, with n dimensions of x and m dimensions of f where f_i = f_i(x_1, ... x_n)?

XPath can be used in Xslt, but not the other way round. In Xslt you can create new elements, while in XPath you can't. Seems like a pretty big difference to me. XPath isn't Turing complete either, while Xslt is.

Re: JMESPath – A query language for JSON

#123

Post by Thiez »

wruza wrote: post #66
mpweiher wrote: post #58

Earlier quoted context omitted.

> and cannot be serialized like jsonlib.encode(foo) Huh? Could have fooled me. In Cocoa, for example, serializing to JSON and serializing to an XML property list (or binary property list) is effectively the same code. https://developer.apple.com/documentation/foundation/nsjsons... https://developer.apple.com/documentation/foundation/nsprope...

Yes, but property list is a subset of XML and Cocoa’s almost internal format. It doesn’t even connect keys to values, probably losing all the xpath/xslt/etc abilities. No custom schema too?

You can still use XPath/Xslt in that scenario, it's just more annoying. Of course it wouldn't be hard to write an Xslt to rewrite the XML so that the keys and values are better connected, so you can query it more easily using XPath.

Re: JMESPath – A query language for JSON

#124

Post by crdoconnor »

avmich wrote: post #102
crdoconnor wrote: post #98

Earlier quoted context omitted.

Ideally, use a library that intelligently parses dates as part of a turing complete validator.

The point is that you can't always avoid scenarios with keeping something updated. List of countries is another example.

The point isn't to avoid it. Of course it's inevitable - that was my point! The point is to use code to validate instead of some markup so that the programmer can use their judgment about how it should be delegated.

I wrote some example code below that shows how you can validate with list of countries in such a way that no code changes will be required when the list changes.

Re: JMESPath – A query language for JSON

#126

Post by spraak »

danbruc wrote: post #116
spraak wrote: post #99

Earlier quoted context omitted.

Is this for an open source project, or anything you'll be publishing? I'd be interested to follow on with the results!

Right now it is just an effort to develop a tool to diagnose and hopefully thereafter fix random performance problems we are experiencing with one of our applications in production. Despite having a small team dedicated to investigating the problems, monitoring every click and function call with Dynatrace, having had a Microsoft SQL server expert look into it, and getting the system audited by one of the big consulti…

Aha, well thanks for sharing this far :)

Re: JMESPath – A query language for JSON

#127

Post by lioeters »

xonix wrote: post #96
lioeters wrote: post #83

Earlier quoted context omitted.

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?

Thanks. I doubt this could be a security issue. Typical usage like so var name = one(users, '[_.id==?].name', 123) uses parameterized queries, same idea as with SQL to eliminate injections.

I see, I should have dug deeper before commenting. Wow, parameterized queries, there's been a lot of thought put into this compact library!

Re: JMESPath – A query language for JSON

#128

Post by crdoconnor »

bshacklett wrote: post #111
crdoconnor wrote: post #28

Earlier quoted context omitted.

The "reinvention" is not complete and will never be necessary. The difference is that XPath is necessary to query XML because it's a botched horribly overcomplicated, designed-by-committee markup language. Except for tools like jq no such language is actually required for JSON because it maps on to language structures that always exist. Neither JSON schema or XML schema are particularly popular - and for good reason.…

There's a lot of benefit to being able to state what keys may be specified in a certain location, though. Look at DSLs like Cloudformation, for instance. Having schema validation could make static analysis of this kind of code much easier to handle. E.g.: Fn::Sub may be used inside of Fn::Join, but the reverse is not true, regardless of the types "returned" by each. It's certainly possible to validate via the api, bu…

>There's a lot of benefit to being able to state what keys may be specified in a certain location, though.

There is. I find examples - snippets of XML/JSON - to be the best way of communicating this - not schema languages.

Re: JMESPath – A query language for JSON

#129

Post by cryptonector »

llimllib wrote: post #110
cryptonector wrote: post #105

Earlier quoted context omitted.

Is there demand for a formal spec for jq? Would that lead to additional implementations? Serious question.

I would love to have a jq lib in every lang, which would probably require a spec

That's fair.
Post reply on HN