Comment by monkeyelite
2 days ago
You’re arguing against a straw man. All major language sql libraries are not based on string manipulation and provide things like escaping, arguments, etc out of the box.
2 days ago
You’re arguing against a straw man. All major language sql libraries are not based on string manipulation and provide things like escaping, arguments, etc out of the box.
Query builders are still an antipattern (what we traditionally think of when we say query builders) because they are still a DSL that (1) you have to learn along with SQL and (2) never map cleanly to actual SQL, so you always have to resort to `.raw` calls when you need anything more complex than a simple SELECT+JOIN.
Even for simple SELECTs, I lost count of how many times I had to enable runtime DEBUG logging in my query builders to get a query that I can copy-paste into my DB client for debugging, data exploring, etc. I should be able to copy-paste my query from code and run it in `psql` with minimal changes.
Raw SQL is the way to go[0]. Period. You just need a thin wrapper on top of it that adds escaping, arguments, type-safety and other QoL.
[0] https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...
That thin wrapper is a query builder.
> antipattern (what we traditionally think of when we say query builders)
1 reply →
I'm with you.
Only for parameterization over scalar values. If you want to do any kind of composition more sophisticated than that, you're either stitching together strings or using some kind of more heavyweight abstraction like an ORM.
That’s because the composition is supposed to be inside sql. Views, functions, etc.
This is another reason why the ORM is a leaky abstraction - it hides all the best features from you.
I suspect the biggest reason those aren't more popular is that they usually have to be stored as state in the database, which isn't what you want when developing an application. You want all of your query logic to be versioned with your application code.
8 replies →
> Only for parameterization over scalar values.
ADO.NET has full support for table-valued parameters.
That's part of .NET Framework and therefore legacy, right? Do the database libraries from recent versions of .NET do this?
In any case, it's just one framework; previous comment said "all major languages". And it's useful to be able to abstract and compose over expressions and predicates and such, not just data values, which this still doesn't help with.
1 reply →