4 ms·
The big problem with macro approaches is that when you get to nontrivial sizes, they get impossible to troubleshoot. You get an error from the SQL engine but th
by yafbum 4y ago
The big problem with macro approaches is that when you get to nontrivial sizes, they get impossible to troubleshoot. You get an error from the SQL engine but that's an on expanded macro. If you've availed yourself of "composability", it's a deep tower of macros, and you typically can't easily tell from the error location and message on the expanded SQL which macro is the cause of the problem. It can become really difficult to maintain.
Good approaches here have some form of higher level validation and error messages, such that by the time the SQL engine gets your query, it runs well almost all the time.
- rollcat 4y agoYou get this problem with any sufficiently tall sandwich of abstractions. SQLAlchemy has a query builder, the DSL is easily directly translatable to actual SQL statements in your head. But since you have the full power of Python at your disposal, it gets quite convenient to abstract away some of the boilerplate. And then some of the common parameters. And then some more stuff, just for good measure. Then you try to bite the sandwich, and half the ingredients go sideways: change one parameter, and the generated SQL can look wildly different, etc. I still think DSLs are superior to macros though; a smart DSL transformer will catch a whole class of errors, while a macro engine like M4 could happily spit out garbage with syntax errors.
- fifilura 4y agoI have also seen this before. The knee-jerk reaction of programmers who are subjected to the imperfection of SQL is to introduce more abstractions. But it is perfectly possible to write correct SQL code. Just like it is possible to solve mathematical equations with pen and paper. I try to accept SQL as it is and avoid any abstractions because they make the query impossible to read. I write my queries top down using CTEs and test manually along the way. And it turns out that 90% of the problems are not in the query logic but with the input data and the two villains of tabular data. Duplicate rows and NULL values.
- habibur 4y agoAbstract INSERT, UPDATE, DELETE and select by id, as these are common idiomatic tasks. And then write sql statements for everything else.
- rscho 4y agoOne could use post 1970's macro technology, allowing far better error tracking https://docs.racket-lang.org/syntax/index.html https://docs.racket-lang.org/syntax/index.html