Discussion: rq query language

[dflemstr]

Since 1.0.0, rq no longer supports its old pre-1.0 query language. Instead, I would like to open up for a discussion about what the new rq query language should look like. Please comment on this issue with your suggestions! I will update this main issue description once we reach consensus about various things.

[crides]

Hi, your project looks very interesting. I found this while looking for a alternative to jq, and also looking for a better syntax for rush. Since rq looks very similar to jq feature wise, my suggestions would be to base the overall syntax on jq's. This should make it easier for people to (hopefully) switch from jq to rq. These are some of the important parts:

1. Indexing arrays/dictionaries shouldn't have its own command/process. Having jq-like indexing means you can have more flexibility;
2. Invoking/calling commands/processes without parentheses is a good idea. This should improve ergonomics while using it in the shell, and also get rid of the weird semicolon argument separator in jq;
3. Lambda/anonymous functions are a new thing in rq. When I took a look at the old examples, I find some of the lambdas would've been useless in jq because of the . (dot) input, although in some other cases I can also see why lambdas would be useful. I saw that the old lambda syntax is based on JS's. That should be fine with most people, although expression grouping for the body of the lambda should be done with () instead of {} (unlike the first example here).

Edit: If rq would be available as a library with a query language that would make it very easy to revive rush, which should be a very useful tool.

Edit 2: If anyone wants to try out rush but find the original is too outdated, here is my fork with minimal changes just to make it compile and work.

[crides]

So just to be clear, this tool cannot be currently used to make queries?

Yes, if you're using the 1.0 version. You can still use pre 1.0 if you want.

Also, is it right that the previous query used JavaScript? If so why didnt it use Rust like the rest of the code?

Yes. I believe it's because it makes it easier for the users to customize the functionalities without digging into Rust code. But I need confirmation from @dflemstr .

Finally, if this tool cant query then why does it say "Record Query" here:

As you said, rq currently cannot be used to make queries. Personally I don't think it's a good idea to release a 1.0 version with the core functionalities ripped out, while the new direction (this issue) is not settled as it causes confusion. But this is the author's choice, and he probably has a good reason for it.

Note: I'm also new here, just trying to help when possible.

[gabriel-fallen]

With jq I personally don't like some "shugary" aspects of the query language like square bracket surrounding for array creation:

jq '[.[] | {message: .commit.message, name: .commit.committer.name}]'

I'd prefer more linear "functional" pipeline akin to

jq '.[] | {message: .commit.message, name: .commit.committer.name} | :into []'

Another consideration is more functionality to work with table data. I would love to see for a query language at least something like Nu shell and at best something like Q. 😃

[gabriel-fallen]

Another JSON query language. Rather verbose and SQL-like but still has nice features worth considering, IMO.

[XVilka]

@gabriel-fallen the Operon link is dead.

[gabriel-fallen]

@XVilka but the Operon itself is evidently not. 😃 Thanks for the heads-up, I've updated the comment.

[PsychoLlama]

Pardon me if this has been asked before, but does rq really need a query language? I've been using this purely as a format conversion tool and it's kind of awesome. I can import a yaml file and query it with jq, easily test MessagePack APIs by converting from plain JSON (and interpret responses), run CSV tools against JSON with xsv, and if it supported TSV output, then even datamash could join the fun.

Point is, rq is immensely useful even without a query language. Why not focus on conversions and offload data manipulation to more specialized tools?

[johantiden]

Great point! Even though I stumbled upon rq while searching for an alternative to jq for queries. I guess that could be a separate project though!

The longevity and success of GNU projects in the past have been how small they can stay. Do one thing and do it really well! It will be easier to take over ownership (or keep maintaining) if the scope is as small as possible.

[gabriel-fallen]

@johantiden on the "success" and "how small" GNU utils are you might find https://danluu.com/cli-complexity/ quite amusing. 😉

[johantiden]

@johantiden on the "success" and "how small" GNU utils are you might find https://danluu.com/cli-complexity/ quite amusing. wink

Nice one! Thanks for sharing!
Amusing and depressing at the same time.

[AndydeCleyre]

I'm an outsider here, as I only discovered this project while it's still considering a next query language, but think it's worth mentioning two different and IMO quite good structured data access and manipulation tools and corresponding syntaxes:

• YAML Path
• dasel