Show HN: JSON Query (opens in new tab)

crucial jq insight which unlocked the tool for me: it's jsonl, not json.

it's a pipeline operating on a stream of independent json terms. The filter is reapplied to every element from the stream. Streams != lists; the latter are just a data type. `.` always points at the current element of the stream. Functions like `select` operate on separate items of the stream, while `map` operates on individual elements of a list. If you want a `map` over all elements of the stream: that's just what jq is, naturally :)

stream of a single element which is a list:

    echo '[1,2,3,4]' | jq .
    # [1,2,3,4]

unpack the list into a stream of separate elements:

    echo '[1,2,3,4]' | jq '.[]'
    # 1
    # 2
    # 3
    # 4
    echo '[1,2,3,4]' | jq '.[] | .' # same: piping into `.` is a NOP:

only keep elements 2 and 4 from the stream, not from the array--there is no array left after .[] :

    echo '[1,2,3,4]' | jq '.[] | select(. % 2 == 0)'
    # 2
    # 4

keep the array:

    echo '[1,2,3,4]' | jq 'map(. * 2)'
    # [2,4,6,8]

map over individual elements of a stream instead:

    echo '[1,2,3,4]' | jq '.[] | . * 2'
    # 2
    # 4
    # 6
    # 8
    printf '1\n2\n3\n4\n' | jq '. * 2' # same

This is how you can do things like

    printf '{"a":{"b":1}}\n{"a":{"b":2}}\n{"a":{"b":3}}\n' | jq 'select(.a.b % 2 == 0) | .a'
    # {"b": 2}

select creates a nested "scope" for the current element in its parens, but restores the outer scope when it exits.

Hope this helps someone else!

Doesn't the command-line utility `jq` already define a protocol for this? How do the syntaxes compare?

(LLMs are already very adept at using `jq` so I would think it was preferable to be able to prompt a system that implements querying inside of source code as "this command uses the same format as `jq`")

You just have to wrap your mind around jq. It's a) functional, b) has pervasive generators and backtracking. So when you write `.a[].b`, which is a lot like `(.a | .[] | .b)` what you get is three generators strung together in an `and_then` fashion: `.a`, then `.[]`, and then `.b`. And here `.a` generates exactly one value, as does `.b`, but `.[]` generates as many values as are in the value produced by `.a`. And obviously `.b` won't run at all if `.a` has no values, and `.b` will run for _each_ value of `.a[]`. Once you begin to see the generators and the backtracking then everything begins to make sense.

DuckDB can read JSON - you can query JSON with normal SQL.[1] I prefer to Malloy Data language for querying as it is 10x simpler than SQL.[2]

[1] - https://duckdb.org/docs/stable/data/json/overview [2] - https://www.malloydata.dev/

I read the man page of `jq` and learned how to use it. It's quite well-written and contains a good introduction.

I've observed that too many users of jq aren't willing to take a few minutes to understand how stream programming works. That investment pays off in spades.

I'd like to know how it compares to https://jsonata.org

https://jsonpath.com/ or https://jsonata.org/

In the k8s world there's a random collection of json path, json query, some random expression language.

Just use jq. None of the other ones are as flexible or widespread and you just end up with frustrated users.

I have a similar use case in the app I'm working on. Initially I went with JSONata, which worked, but resulted in queries that indeed felt more like incantations and were difficult even for me to understand (let alone my users).

I then switched to JavaScript / TypeScript, which I found much better overall: it's understandable to basically every developer, and LLMs are very good at it. So now in my app I have a button wherever a TypeScript snippet is required that asks the LLM for its implementation, and even "weak" models one-shot it correctly 99% of the times.

It's definitely more difficult to set up, though, as it requires a sandbox where you can run the code without fears. In my app I use QuickJS, which works very well for my use case, but might not be performant enough in other contexts.

"JSON Query" is kind of a long name. You should find a way to shorten it. Maybe "jQuery" or something along those lines :P

I can't help myself and surely someone else has already done the same. But the query

  obj.friends.filter(x=>{ return x.city=='New York'})
  .sort((a, b) => a.age - b.age)
  .map(item => ({ name: item.name, age: item.age }));

does exactly the same without any plugin.

am I missing something?

Most alternatives being talked about are working on query strings (like `$.phoneNumbers[:1].type`) which is fine but can not be easily modeled / modified by code.

Things like https://jsonlogic.com/ works better if you wish to expose a rest api with a defined query schema or something like that. Instead of accepting a query `string`. This seems better as in you have a string format and a concrete JSON format. Also APIs to convert between them.

Also, if you are building a filter interface, having a structured representation helps:

https://react-querybuilder.js.org/demo?outputMode=export&exp...

.friends | filter(.city == "New York") | sort(.age) | pick(.name, .age)

mapValues(mapKeys(substring(get(), 0, 10)))

This is all too cute. Why not just use JavaScript syntax? You can limit it to the exact amount of functionality you want for whatever reason it is you want to limit it.

Lot of people focus on a similarity to jq et al, I guess the author had his reasons to craft own stuff.

Kudos for all the work, it's a nice language. I find writing parsers a very mind-expanding activity.

I've been working on an ultra-token-efficient LLM-friendly query language. https://memelang.net/09/

If you prefer JSONPath as a query language, oj from https://github.com/ohler55/ojg provides that functionality. It can also be installed with brew. (disclaimer, I'm the author of OjG)

There are a ridiculous number of JSON query/path languages. Wish all the authors got together and harmonized on a standard.

https://www.jsoniq.org -- jq is ubiquitous, but I still prefer the jsoniq syntax.

jq is amazing (not only for querying json), I recommend going though the docs, it's fairly small.

I implemented one day of advent of code in jq to learn it: https://github.com/ivanjermakov/adventofcode/blob/master/aoc...

What do your users know? If they’re quite familiar with SQL for querying, I would look at duckdb.

Nice work with a jq-esque feel. Website is cut on mobile devices though

Maybe JS directly?

Nice. I work on something similar but for .net.

I hate jq as much as the next guy but it’s ubiquitous and great for this sort of thing. If you want a single path style query language I’d highly recommend JsonPath. It’s so much nicer than jq for “I need every student’s gpa”.

not to be confused with jq for querying json?