jql

For everyone pining for a Jq with a different syntax: I have a bunch of links to alternatives collected, you might want to try some of them (some may be for different things than JSON): https://github.com/fiatjaf/awesome-jq https://github.com/TomConlin/json2xpath https://github.com/antonmedv/fx https://github.com/fiatjaf/jiq https://github.com/simeji/jid https://github.com/jmespath/jp https://github.com/cube2222/jql https://jsonnet.org https://github.com/borkdude/jet https://github.com/jzelinskie/faq https://github.com/dflemstr/rq Personally I think that next time I might just fire up Hy and use its functional capabilities.

Check out jql [https://github.com/cube2222/jql] and oj [https://github.com/ohler55/ojg]

If so, and for anybody else having this wish, check out jql[0], I've created it exactly for this reason, to have the most common jq operations available in a more uniform and easier to use interface. [0]: https://github.com/cube2222/jql

I agree, jq is very advanced when everything most people want is simple json transformation and highlighting. I've made jql[0] for that reason. Check it out, it's less featureful, but much simpler with a uniform lispy syntax. [0]: https://github.com/cube2222/jql

Nice project! Though as others already said, you can use fzf very effectively to get a GUI-like experience for such tools. If you're not a fan of jq for its syntax, check out jql[1]. It too helps you to transform json files, but does so with a consistent, lispy syntax. [1]:https://github.com/cube2222/jql

As people always do in such threads, I’d too like to chime in with alternatives I’ve been a co-author of, as this is an area I’m very interested in. The first one, which is definitely close in spirit to this project is OctoSQL[1]. We too are trying to query all the things with SQL, including JSON, though we extended the idea to supporting more data sources and file formats, with the ability to mix and match in joins and subqueries. Curious what direction this project will take though, as we’re now heading for streaming sources (like Kafka) in pure SQL! A totally different one is jql[2] where I’ve been exploring more of a lispy continuation passing style based approach to a JSON query language, as I didn’t really feel like the current ones are ergonomic. If you like this, make sure to check them out too! (And all the others people will be

A project I'm using, which I'm also one of the authors of, is OctoSQL[1]. It allows you to transform and join data from different data sources (including databases like mysql, postgres, redis, and CSV or JSON files, more to come) using a familiar interface - plain SQL. Other than that, I like Exploratory[2]. And for nested JSON data I use another project of mine, jql[3] - an easier to use (in my opinion) lispy alternative to jq. (originally inspired by a hackernews comment actually) [1]:https://github.com/cube2222/octosql [2]:https://exploratory.io [3]:https://github.com/cube2222/jql

Why? It is, it's just that everything returns a function! The topmost function will in the end be called with the json as an argument. Check out these parts of the README: https://github.com/cube2222/jql#attention https://github.com/cube2222/jql#type-cheatsheet (elem 0) returns a function which takes a JSON array as input and returns its first element.

Hey, author here. Christmas Eve, 22 pm, after having eaten with my family, I was browsing HN (because what else could you be doing then), and stumbled upon this comment: https://news.ycombinator.com/item?id=21860107 It inspired me to create an alternative to jq with more of a Lispy syntax, as I think the original is awesome but also fairly cryptic for anything more advanced than single field selection. Overall it was a fun few-day project, and was also very educational in terms of writing a parser in Go. (I used goyacc before in the sql parser of OctoSQL[1], however, that one is copied from vitess, so I’ve never built one from scratch, only customised an existing one. It’s really pleasant overall and the code is very simple, so I encourage you to take a look[2]. I'd love to hear any feedback, comments or potential improvements you can thi