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

Sq.io: jq for databases and more

sq.io

Post reply on HN
Print view View original

91–100 of 134 posts

Re: Sq.io: jq for databases and more

#91

Post by neilotoole »

remon wrote: post #49
dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

HN is inundated with posts announcing paper thin abstractions on top of existing technology or utilities that just move the goalpost of what you knowledge you need to be effective. It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume, or seek funding if its a startup.

> It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume

Developer here. I can't speak to what you see as the weird trend, but I can speak about sq's history:

- I created the first version of sq circa 2013 as my own personal dev tool to address some pain points (amongst other things: getting JSON out of various DBs from the command line in a consistent manner, and wanting an easy way to inspect DB schemas, i.e. "sq inspect")

- It was starting to be a minor PITA dealing with colleagues asking for the latest revision of the tool, so I open-sourced it. In 2016 or so I think?

- sq is FL/OSS and will remain so, no funding is sought, not even one of those "buy me a coffee" thingies

- I didn't create this HN post about sq, nor do I know the person who did. But thanks for sq's 15 mins of fame, kind stranger

Re: Sq.io: jq for databases and more

#92

Post by neilotoole »

6LLvveMx2koXfwn wrote: post #63
dlisboa wrote: post #58

Earlier quoted context omitted.

> It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume That’s really harsh and misguided. If people didn’t do “paper thin abstractions” projects on their own time for the simple pleasure of doing it we wouldn’t have 90% of the successful projects we have today. Let people have fun and don’t judge their motives when they’re making something Open Source. I can g…

Unless you're the GP your guarantee about the persons motivation is as meaningless as the post you're replying to.

I'm not GP, but I am the sq developer.

> the person just thought “this would be cool to have” and implemented it.

Correct. This is true of much OSS, or at least I've always suspected so.

Re: Sq.io: jq for databases and more

#93

Post by neilotoole »

mattbrewsbytes wrote: post #84
dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

The sq and jq tools are both neat command line gimmicks but in my workflow their usefulness is very short. I can't imagine using sq on a query involving a handful of tables and some inner/outer joins. How would I know its outputting the correct SQL? If you mess up joins you end up with bad output. Here's my theory: some developers see simple languages that are easy to learn and want to build something more complex to…

> How would I know its outputting the correct SQL? If you mess up joins you end up with bad output.

The generated SQL is output in sq's logs, when logging is enabled.

https://sq.io/docs/config#logging

Re: Sq.io: jq for databases and more

#94

Post by 8338550bff96 »

dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

Lots of people struggle to understand the declarative programming language paradigm. It is really pesky because since you're declaring what kinds of results you expect rather than dictating what must be done, you're forced to define your boundary conditions up-front. Much more fun and exciting to charge ahead without worrying about such things

Re: Sq.io: jq for databases and more

#95

Post by neilotoole »

hnbad wrote: post #44
rout39574 wrote: post #11

I love JQ. But ... I'd never considered its query language to be particularly admirable. If I want to ask questions of some databases, I don't understand why I'd choose JQ's XPATH-like language to do it.

Presumably the target audience is people who already frequently use JQ and don't want to juggle different query languages when dealing with different data sources?

Developer here.

That was exactly the target audience.

Note that sq doesn't just handle relational DBs, it also has (varying quality) support for CSV, JSON, Excel, and so on. At the time (2013) I wasn't aware of a convenient one-liner mechanism for munging all of those together from the command line.

Re: Sq.io: jq for databases and more

#96

Post by neilotoole »

nashashmi wrote: post #65

> sq is pronounced like seek. Its query language, SLQ, is pronounced like sleek As a person who is apart from the tech scene, and lurks in the tech space out of interest, I appreciate this guidance. For the longest time I didn’t know nginx was pronounced Engine-X; I called it N-jinx.

The theory at the time was that if "SQL" is pronounced like "sequel", and "sq" is just dropping the "L" from "SQL", then "sq" must be...

I suspect the uptake on the "seek" pronunciation is about 2%, if I'm being generous

Re: Sq.io: jq for databases and more

#97

Post by goosejuice »

dewey wrote: post #48

Sometimes I wonder if it wouldn't be more efficient for people to just learn SQL instead of trying to build tools or layers on top of it that introduce more complexities and are harder to search for.

There are a several features here that go beyond 'learn SQL'. I don't see how you could jump to this conclusion if you read the docs.

Why does pgcli exist. What about dbeaver, datagrip, pgadmin, postico, LINQ, ORMs? It's almost as if people value different interfaces to databases.

Maybe it's not for you, but it's not hard to imagine that someone, beyond the author, might find it useful. Maybe it's just me but to dismiss those people as individuals that should just 'learn SQL' is a pretty rude thing to say.

Re: Sq.io: jq for databases and more

#98

Post by jimbokun »

dewey wrote: post #56
zmmmmm wrote: post #54

Earlier quoted context omitted.

I think it'd be a moot point if SQL wasn't painful and awkward to work with in the first place. But database purists control it and won't let go, so we will have to live with everyone else inventing layers to make their lives easier.

For me this feels like the complaints about error handling in Go. People who work with it all the time, don't even think about it past the first week. If you are starting out it might bother people because they are not used to it. Personally I really like working with SQL and find it quite elegant, I always encourage people to use it as it really is a job-superpower if you can just dig up issues directly in the DB qu…

I like Go a lot and can work with it's error handling paradigm, but I still often wonder if the same semantics could be accomplished with less verbosity in a way that makes the underlying algorithm more clear when reading the code.

Re: Sq.io: jq for databases and more

#99

Post by neilotoole »

candiddevmike wrote: post #4

This is neat but I'm not really seeing anything I can't do with standard SQL and CLI tools like psql. Seems like you'd learn more reusable things using standard SQL too.

> I'm not really seeing anything I can't do with standard SQL and CLI tools like psql.

Developer here. There's a few features other than the query stuff that I still think are pretty handy.

The "sq inspect" stuff isn't easy to do with the standard CLI tools, or at least wasn't when I started working on sq back in 2013 or so.

https://sq.io/docs/inspect

I also regularly make use of the ability to diff the metadata/schema of different DB instances (e.g. "sq diff @pg_prod @pg_qa").

https://sq.io/docs/diff

Post reply on HN