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

I don't need your query language

antonz.org

Post reply on HN
Print view View original

161–170 of 304 posts

Re: I don't need your query language

#161

Post by rjbwork »

hfkwer wrote: post #121
rjbwork wrote: post #108

Earlier quoted context omitted.

Gods, I tried to do some reflection stuff in a Node TS project I got put on about 18-24 months ago, and it was a total shit show. It was really disappointing to see how lacking the actual runtime capabilities of TS are.

There are no TS runtime capabilities. This isn't a thing.

There are some libraries that allow you to do some stuff. You can attach metadata to some objects about types in some contexts. But obviously it's bolted on because under the hood it's all Javascript.

Re: I don't need your query language

#162

Post by 0x445442 »

nine_k wrote: post #63
gemstones wrote: post #49

Earlier quoted context omitted.

Yup, this right here. This aspect of SQL is overwhelmingly why I insist on ORMs, too. Any efficiency gains you get by having a senior dev write raw SQL for a complex query are immediately negated by a junior turning what an ORM would write as a single query into three DB calls. All because SQL insists on a flat result set you have to turn into a nested collection yourself, without an ORM doing it for you with eager l…

From my experience, ORMs in hands of junior.developers who happen to not yet know SQL are a disaster. However hard the ORMs may try, the code ends up making a ton of small queries instead of one efficient query, and fetching a ton of unused columns. The developers then end up doing joins manually in application code, some distance further from the place of the original queries. ORMs also tend to sneak "live" objects…

These problems have been “solved” by designing micro services that don’t perform any joins but shift that responsibility to the applications. What was once a single API call for the application, backed by a SQL query joining over tables has been replaced by multiple micro service calls. It’s now the application’s responsibility to hold these MS call results in memory and then relate them once all the data has been fetched. This works well because the failure rate of http requests is so much lower than a DB query. And after all, the further away the code from the data the better equipped it is to reason about the data.

Re: I don't need your query language

#163

Post by 6510 »

frogulis wrote: post #11
XorNot wrote: post #5

Earlier quoted context omitted.

FROM users SELECT name, id, location WHERE name LIKE 'a%'; You know I think you're right.

Go further: `FROM users WHERE name LIKE 'a%' SELECT name, id, location` - after all, you can WHERE on things that aren't projected by SELECT

A human would grab the paper with the right table on it then search for the row he wants with his finger and finally gets the phone number from the row.

Re: I don't need your query language

#164

Post by tomnipotent »

remram wrote: post #159
tomnipotent wrote: post #142

Earlier quoted context omitted.

> it's.objective. Prove it. > You're just clearly someone who can't admit when they're wrong You don't have a good technical argument so you jump to ad-hominem's?

They've presented plenty of drawbacks, which you've dismissed as "it's not that bad", while not presenting any benefit.

I've presented the bandwidth vs. memory and CPU trade-off, was that not obvious? Not to mention reduced network round trips, and less overhead on transaction management.

If the biggest issue in my product is JSON deser, I'd be a happy camper.

Re: I don't need your query language

#165

Post by DaiPlusPlus »

0x445442 wrote: post #162
nine_k wrote: post #63

Earlier quoted context omitted.

From my experience, ORMs in hands of junior.developers who happen to not yet know SQL are a disaster. However hard the ORMs may try, the code ends up making a ton of small queries instead of one efficient query, and fetching a ton of unused columns. The developers then end up doing joins manually in application code, some distance further from the place of the original queries. ORMs also tend to sneak "live" objects…

These problems have been “solved” by designing micro services that don’t perform any joins but shift that responsibility to the applications. What was once a single API call for the application, backed by a SQL query joining over tables has been replaced by multiple micro service calls. It’s now the application’s responsibility to hold these MS call results in memory and then relate them once all the data has been fe…

> These problems have been “solved” by designing micro services that don’t perform any joins but shift that responsibility to the applications

This is utter nonsense. There is absolutely nothing about microservices architecture that relates to performing JOINs in SQL.

Re: I don't need your query language

#166

Post by camgunz »

LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

Just start with `SELECT *` and sculpt w/ autocomplete afterwards as you like.

Re: I don't need your query language

#167

Post by rebataur »

Actually SQL is pretty cool and by using concatenative concepts, you could do some pretty cool stuff.

We built a datascience tool to quickly build data apps which can be extended from the frontend, including data wrangling and datascience functions. Most exciting part was using the PostgreSQL and SQL to process, clean and enhance data and write extensions and bring it all together.

We open sourced alpha version yesterday, more documentation to come.

https://github.com/rebataur/rapidiam

Re: I don't need your query language

#168

Post by vbezhenar »

password4321 wrote: post #134
411111111111111 wrote: post #122

Earlier quoted context omitted.

The funnest part of outputting JSON from the query is that your API now basically becomes a RPC, as you don't have to do any marshalling/deserialization before returning the response with Content-Type application/json Response times are really fast like that, as you probably already know. Always fun to see Also no worry about n+1 queries, as they're fundamentally impossible to do like that

I've long wondered if there would be any performance advantage for an API server to zero-copy the DB response to the browser, deserializing from the DB wire protocol on the front end. Or perhaps sending DB query results directly from DB server to browser, with the API server just initializing and securing. Thanks for pointing out how JSON from the DB is another option for moving a bit of processing elsewhere in the s…

TLS everywhere makes the whole point of zero copying obsolete. Encryption eats so much CPU that copying data around does not change anything.

Re: I don't need your query language

#169

Post by blipvert »

XorNot wrote: post #5
LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

FROM users SELECT name, id, location WHERE name LIKE 'a%'; You know I think you're right.

I might be wrong, but there’s nothing to stop a front end UI from accepting this syntax and then writing out canonical SQL to do the actual query, is there?

Re: I don't need your query language

#170

Post by kwkelly »

Fissionary wrote: post #125
danielheath wrote: post #19

Earlier quoted context omitted.

This is also my primary issue with vi. d3w (`d`elete `3 w`ords) cannot be highlighted / indicated in any way ahead of time. If the motion specifier came first, it could be.

You might like kakoune ( https://github.com/mawww/kakoune ), which does exactly that: first you select the range (which can even be disjoint, e.g. all words matching a regex), then you operate on it. By default, the selected range is the character under cursor, and multiple cursors work out of the box. It's also generally lean and follows the Unix philosophy, e.g. by using shell script, pipes, and built-in Unix utili…

Helix[1] is another editor which heavily borrows from kakoune’s “selection then action” paradigm. The editor is very good, but still in heavy development, so it lacks plugins and has the occasional rough edge. [1] https://helix-editor.com
Post reply on HN