3 ms·
Once you break free of ORM’s I find the code so much simpler to maintain. Here’s the query(typically multiple different subqueries and return types), here’s th
by grebc 4mo ago
Once you break free of ORM’s I find the code so much simpler to maintain.
Here’s the query(typically multiple different subqueries and return types), here’s the params, give me all the data back and something like Dapper in .net is an absolute godsend to convert it.
- gonzalohm 4mo agoThe code is simple to maintain until the database changes. Then you will experience the pain of SQL
- grebc 4mo agoI’ve experienced what you’ve mentioned before, ORM or not you have issues if you’re shuffling the schema around. Cool.
- trumpdong 4mo agoIt would be great if there was a compiler that would check your SQL queries against the schema, and you could even refactor a column name to update both the schema and the queries.
- anonymars 4mo agoMicrosoft SSDT (SQL Server Data Tools), but I think it only works against Microsoft SQL Server https://learn.microsoft.com/en-us/sql/ssdt/sql-server-data-tools?view=sql-server-ver17#core-sql-server-data-tools https://learn.microsoft.com/en-us/sql/ssdt/sql-server-data-t...
- bbkane 4mo agoData schema changes are difficult, almost regardless of technology - it's been an issue for me from relational dbs to OpenAPIs. gRPC is easier as long as you obey the migration rules, but those impose tight restrictions on what you can change
- skydhash 4mo agoBy the time you really needs to change your database, updating your queries will be the easiest part, compared to reviewing the semantic changes and the data migration.