3 ms·
> Nothing like that is happening here, right? You cannot validate this SQL at compile/build time? If not, aren't you YOLO riding the motorcycle but telling mom
by surprisetalk 3y ago
> Nothing like that is happening here, right? You cannot validate this SQL at compile/build time? If not, aren't you YOLO riding the motorcycle but telling mom you are wearing your helmet?
Correct! It's a total pain haha.
I loathe SQL, but it's the best tool for most modern web apps.
All of flashcasts.com is 1800 lines. I'd guess 30% is HTML and 30% is SQL.
The SQL does the vast majority of the heavy lifting if you think about moving bits over distances.
So SQL is really important, but why don't I have any safeguards? Well, in my experience, the available safeguards are medicine more painful than the poison.
For example, any of the queries in my app I can copy-and-paste into psql and start an interactive debugging session. Can't do that with ORMs.
In my app, I dynamically aggregate and build all the podcast XML for every feed in a single Postgres query. It's super performant and surprisingly little SQL. Can't imagine doing that through an ORM.
SQL queries will throw an error if they're not well formatted, so you just have to write a test suite that somehow hits every query exactly once. You can do this by separating out your SQL, or integration tests, or a handful of other methods, none of which are pleasant.
Anyway, I'm tired of SQL, sol I'm working on an embedded query language in scrapscript. Stay tuned for details:
[1] https://scrapscript.org https://scrapscript.org
- paulryanrogers 3y agoIsn't there a risk of SQL injection from user input?
- surprisetalk 3y agopostgres.js sanitizes inputs, but also provides a backdoor, so sql`select ${"hello"}, ${sql`world`}` becomes select $1, world [1] https://github.com/porsager/postgres https://github.com/porsager/postgres