5 ms·
I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. Fo
by adriancooney 6y ago
I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. For me personally, I'd be hesitant to add another build tool to my already bloated toolchain. Could create a special Babel-style "import" type that automatically transforms your code (JIT)? It could remove some of the friction in adoption (for Babel users at least).
Another one in a similar vein with strict typing and really nice SQL interpolation for Postgres: https://github.com/gajus/slonik https://github.com/gajus/slonik
- ggregoire 6y agoSame, I really like this approach. Some of the benefits are: - better separation of concerns - better integration with SQL tools (syntax highlighting, autocompletion, etc) - way easier to run/test/debug your queries into a database client - better languages analysis of your projects (e.g. % of SQL in your GitHub/GitLab repo) -- If anyone interested in applying this approach in your Python projects, I recommend this package: https://github.com/mcfunley/pugsql https://github.com/mcfunley/pugsql
- goofiw 6y agoI wonder if the JIT compiling will work asynchronously - from the readme it's getting the types from the live database schema.
- goofiw 6y agoIts actually doing the with what looks like a custom async messaging queu. Pretty cool.
- hn_throwaway_99 6y agoCan't say enough good things about slonik. Have been using it in production for a while now and I love it. For people like me who believe "abstracting away SQL" is a mistake, but still want protections against SQL injections and a nice API, slonik is a godsend.