3 ms·
Oh man this is the opposite of my experience! Copilot has replaced almost all of the annoying tedious stuff, especially stuff like writing (simple) SQL queries
by thepasswordis 3y ago
Oh man this is the opposite of my experience!
Copilot has replaced almost all of the annoying tedious stuff, especially stuff like writing (simple) SQL queries.
“Parse this json and put the fields into the database where they belong” is a fantastic use case for copilot writing SQL.
(Yes I’m sure there’s an ORM plugin or some middleware I could write, but in an MVP, or a mock-up, that’s too much pre optimization)
- JBorrow 3y agoAn ORM is not too much pre optimisation…
- crabmusket 3y agoYeah MVPs and mockups is exactly what ORMs are for, since they get you the first 80% for very little effort. Maybe it depends on the language, but this is definitely the way Rails and Laravel style framework ORMs are designed.
- mewpmewp2 3y agoTo me SQL is better for MVPs. It is transparent and clear, easy to debug and can do easily whatever joins, filtering you want to. ORM is more for future, because it abstracts away the database implementation, so you could in theory change the db or change some behaviour more simply. E.g. if you add something like deleted_at column, ORM can have a single place where to configure system to use it, but if you have SQL queries lying around you may need to find all spots to add that to your where clauses everywhere. But otherwise SQL is easier to work with in my view.
- crabmusket 3y agoWhat ORMs/languages do you usually work with? Dynamic language ORMs usually let you very easily add filters, work with relationships, etc.
- mewpmewp2 3y agoI started out with Laravel 10 years ago, but now I have been in the NodeJS Ecosystem for recent 5 years, so I've been working with different things, but lately mostly with Supabase, which has its own REST API abstraction, but now I've been lately starting to prefer just having a direct bare postgres client against it. This is for my own side projects/MVPs.
- alexanderchr 3y agoYeah I’ve found both Eloquent (Laravel ORM) and Entity Framework to be more than flexible enough and to produce surprisingly good SQL. You do need to keep an eye on the queries if produces though because innocent changes can make a huge difference in performance.
- mewpmewp2 3y agoORMs can be annoying to use in my experience, especially with more complex queries, joins, counts, filtering by joins etc. And they make debugging harder usually.
- dgan 3y agoI don't know, i don't think ever came across something I wasn't able to express in SQLAlchemy... And I prefer all the goodies that come with it than writing raw sql
- speleding 3y agoSince I found out that ChatGPT does a really nice job of "Show me what ActiveRecord query would generate this SQL query", and vice versa, it's gotten quite a bit easier. It handles some surprisingly complex stuff
- randomdata 3y agoThere is no avoiding object-relational mapping, though, unless you intend to carry relations (sets of tuples) from start to finish. Something you almost certainly cannot do if you interface with any third-party code – which will expect language-native structures. It's just a question of whether you want to use a toolkit to help the transformations, or if you want to 'do it by hand'.