This was my first approach in realizing my PostgreSQL-centric, Db-first, or rather SQL-first vision of software development.
The project was call pgroutiner and it generated bunch of C# code for me out of PostgreSQL.
After doing couple of projects with it, I realized it wasn't enough. The new approach is a dynamic HTTTP REST API generation but, with plugin for code generation of frontend files (Typescript,. Javascript, HTTP files). This iw way better approach. Look it up, it's called npgsqlrest.github.io
Neat! Even-though they should probably use a custom type rather than the generic "Stream" to communicate that this needs to be closed. Or remove the try-with-resource block if closing is not necessary.
This way it leaves some room for misinterpretation.
This was my first approach in realizing my PostgreSQL-centric, Db-first, or rather SQL-first vision of software development.
The project was call pgroutiner and it generated bunch of C# code for me out of PostgreSQL.
After doing couple of projects with it, I realized it wasn't enough. The new approach is a dynamic HTTTP REST API generation but, with plugin for code generation of frontend files (Typescript,. Javascript, HTTP files). This iw way better approach. Look it up, it's called npgsqlrest.github.io
How often is this approach useful? Why not just send the SQL to the DB and get the records you need, do you have big collections of records in memory?
Neat! Even-though they should probably use a custom type rather than the generic "Stream" to communicate that this needs to be closed. Or remove the try-with-resource block if closing is not necessary.
This way it leaves some room for misinterpretation.
Thank you for the suggestion!
How does SQG compare to SQLDelight, for someone only interested in Kotlin and PostgreSQL?
Love SQLC, this looks good too. Syntax is almost identical.