Because you never learned SQL properly, from the sound of it.
You might be right, though, to be fair, I also keep forgetting syntax of stuff when I don’t use it very often (read SQL (._.`))
Also, ORMa produce trash queries and are never expressive enough.
I meant to say that I would like the raw SQL syntax to be more similar to other programming languages to avoid needing to switch between thinking about different flows of logic
No. The arrow function in where eliminates any possibility of using indexes. And how do you propose to deal with logical expressions without resorting to shit like .orWhereNot() and callback hell? And, most importantly, what about joins?
Me trying to remember on whose output data
having,count,sum, etc. workOnce you know functions you would have no reason to go back.
I propose we make SQL into this:
const MAX_AMOUNT = 42, MIN_BATCHES = 2 database .from(table) .where( (amount) => amount < MAX_AMOUNT, table.field3 ) .select(table.field1, table.field3) .group_by(table.field1) .having( (id) => count(id) >MIN_BATCHES table.field0 )(Sorry for any glaring mistakes, I’m too lazy right now to know what I’m doing)
…and I bet I just reinvented the wheel, maybe some JavaScript ORM?
Because you never learned SQL properly, from the sound of it.
Also, ORMs produce trash queries and are never expressive enough.
You might be right, though, to be fair, I also keep forgetting syntax of stuff when I don’t use it very often (read SQL (._.`))
I meant to say that I would like the raw SQL syntax to be more similar to other programming languages to avoid needing to switch between thinking about different flows of logic
ORMs produce good queries if you know what you do. Which requires proper knowledge of SQL, unfortunately.
Well, if you lose the OOPism of those dots, we can talk.
Anyway, I’m really against the “having” tag. You need another keyword so that you can apply your filter after the group by?
That’s a good point, I didn’t even think about it, maybe a more functional style would make more sense?
Boy then are you going to hate
QUALIFYYes, I do. It’s a lot of effort and hidden functionality to try to paper over the fact that the statements do not compose.
Check out Spark: https://github.com/apache/spark/blob/master/examples/src/main/python/sql/basic.py
Thanks for the suggestion! It looks interesting, not quite what I expected looking at that file*, but that may very well be better
Edit: other examples seem a bit more similar to mine, cool!
No. The arrow function in where eliminates any possibility of using indexes. And how do you propose to deal with logical expressions without resorting to shit like
.orWhereNot()and callback hell? And, most importantly, what about joins?