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

81–90 of 134 posts

Re: Sq.io: jq for databases and more

#81

Post by mschuster91 »

seanhunter wrote: post #73
mschuster91 wrote: post #70

Earlier quoted context omitted.

Out of the random shit I had to deal with CSV file wrangling in the last two years: - no defined encoding, so it may be anything from US-ASCII over ISO-8859-x to UTF-8 and it's always a guesswork what it actually is - no definition of the separator sign, usually it can be a literal comma, a semicolon, or tabs - escaping of the separator sign in column values is always fun - escaping of newlines is even MORE fun - lin…

Most of these issues while real don't actually arise in this case, because we're not trying to ETL some random file, we are the ones talking to the database so we get to choose exactly how the data gets formatted on extract. For example, here's your list fully handled in postgres: 1. SET CLIENT_ENCODING TO 'value'; (eg 'UTF8') 2. COPY ... with FORMAT CSV DELIMITER 'delimiter_character' QUOTE 'quote_character' Now the…

Yeah, the problem is not every application can read such files. Particularly when newlines are involved, it's a hit and miss.

Re: Sq.io: jq for databases and more

#82

Post by deskr »

wvh wrote: post #71
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.

Don't sweat it. It's a running joke amongst guitar players no two people pronounce D'Addario the same way, not to mention the tremolo bar which technically should be called a vibrato bar. I surmise any scene has its trip-up words.

D'Addario is of course pronounced "Dadda Rio", with emphasis on Rio and a slight Italian accent.

Re: Sq.io: jq for databases and more

#84

Post by mattbrewsbytes »

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 output that language. Maybe its a sub-conscious thing.

HTML is another one, if explained simply, HTML and CSS basic use cases should be easy-ish to pick up by nearly anyone. The fact that we have so many over-engineered frameworks and libraries out there that generate these is evidence of over complicating simple things. Maybe its called resume driven development? Maybe people see genuine useful frameworks that get wide adoption and are wannabes?

Re: Sq.io: jq for databases and more

#85

Post by seanhunter »

mschuster91 wrote: post #81
seanhunter wrote: post #73

Earlier quoted context omitted.

Most of these issues while real don't actually arise in this case, because we're not trying to ETL some random file, we are the ones talking to the database so we get to choose exactly how the data gets formatted on extract. For example, here's your list fully handled in postgres: 1. SET CLIENT_ENCODING TO 'value'; (eg 'UTF8') 2. COPY ... with FORMAT CSV DELIMITER 'delimiter_character' QUOTE 'quote_character' Now the…

Yeah, the problem is not every application can read such files . Particularly when newlines are involved, it's a hit and miss.

Well not every application can read any file and either way "sq" isn't going going to make any difference. Like I said they are real issues but don't arise in this case.

Re: Sq.io: jq for databases and more

#86

Post by pie_flavor »

VMG wrote: post #55
pkkm wrote: post #39

Earlier quoted context omitted.

Sounds like PRQL [1]. [1] https://prql-lang.org/

Kind of. However on first glance it seems like the separator in PRQL is a newline instead of a `|`, which is less ergonomic in a shell.

Newline and pipe mean the same thing and are interchangeable.

Re: Sq.io: jq for databases and more

#87

Post by lnxg33k1 »

It is great, I installed it, only thing I'd suggest, probably minor, is to also extract the commands to install from the bash script, and put them in the `Install` section directly, I don't run .sh script, especially if they need privileges, so I went through the bash script to take the commands for debian, they're there, probably could also be outside for other kind of people

Re: Sq.io: jq for databases and more

#88

Post by consteval »

zmmmmm wrote: post #54
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.

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.

I truly have never understood this mentality. To me, SQL is very convenient and quick to work with. It's extraordinarily painless.

I've done data processing in Perl and Python before. THAT is painful. What I think people don't realize is that doing procedural "querying" in a typical PL is, like, 10x the amount of code as an equivalent SQL query. I don't see how the alternative is much better.

SQL just doesn't work like a typical PL, but that's a good thing.

Re: Sq.io: jq for databases and more

#89

Post by zie »

masklinn wrote: post #28
zie wrote: post #24

Earlier quoted context omitted.

In PostgreSQL, you can just select against JSON and query away to your hearts content. They have JSON data types and functions to work on it.

That’s pretty much just jq though, you have bespoke json querying capabilities in sql but you’re not sql-querying your json. At least not before postgres 17, in the latter json_table does provide this capability.

Thankfully PG17 is released and ready for production querying needs!

Re: Sq.io: jq for databases and more

#90

Post by freedomben »

Xenoamorphous wrote: post #60
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.

It's funny because recently a "full stack" dev who's in reality 95% frontend was telling me he's not a fan of Tailwind and that he'd rather learn "proper" CSS. And the irony is of course, he never wants to use a relational DB to avoid SQL, so No-SQL DB it is.

I've unfortunately met a number of "full stack" devs recently that are clearly 95% frontend as well, and have a very similar attitude as that person toward backend tech in general. We of course should not take such a small sample size and draw any sort of conclusions, but it's definitely a trend I'm looking out for now whenever someone claims to be "full stack." If the only backend stuff you've done is Firebase, or just a handful of serverless functions that don't do much, or if the "backend" you have in mind is just SSR-ing templates into HTML, then you really should qualify any claims about backend.

One recently after

Post reply on HN