I politely disagree, because it is hard to format SQL in Go code and with many placeholders it becomes even worse, .e.g. you have a huge template string with ? or %s and then 10 or so arguments.
I find Bun more readable in such cases.
Can't bun do joins?
It can and it even generates even better joins in some cases than, for example, GORM
I like the column-selection in your ORM: "except" would be a great contribution to the SQL standard.
On syntax we will continue to disagree. $ parameter substitution is fine with me.
ORM's are great when CRUD-api's are not an anti-pattern, I'd consider using Bun then. But CRUD is an anti-pattern in most cases.
From what I see in Bun it is a ORM where one can at least try to do SQL close to 1-on-1, that is good news and absolutely vital for considering it.
I'll look into it further.
Thx for the heads up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I politely disagree, because it is hard to format SQL in Go code and with many placeholders it becomes even worse, .e.g. you have a huge template string with
?or%sand then 10 or so arguments.I find Bun more readable in such cases.
It can and it even generates even better joins in some cases than, for example, GORM
If you mean N+1 queries then no, Bun is able to generate joins instead of using sub-queries.
As for the generating queries and scanning, the overhead is very small compared.
I like the column-selection in your ORM: "except" would be a great contribution to the SQL standard.
On syntax we will continue to disagree. $ parameter substitution is fine with me.
ORM's are great when CRUD-api's are not an anti-pattern, I'd consider using Bun then. But CRUD is an anti-pattern in most cases.
From what I see in Bun it is a ORM where one can at least try to do SQL close to 1-on-1, that is good news and absolutely vital for considering it.
I'll look into it further.
Thx for the heads up.