Comment by bkummel

Comment by bkummel 4 days ago

Frameworks that do “everything” are not a good idea. I’m from the Java ecosystem. Spring is the “batteries included” framework there. If you have migrated any real world application to a new major version once, you’ve learned forever that “all in one” frameworks are bad. Please don’t do it!

Instead, use scaffolding tools, that give you a head start on creating a new project, using smaller, specialized libs.

Also, don’t use an ORM. Just write that SQL. Your future self will be thankful.

stavros 4 days ago

> Also, don’t use an ORM. Just write that SQL. Your future self will be thankful.

I have never understood this. I've been using the ORM for twenty years now, it's saved me countless hours, and I've very rarely needed to break out of it. When I did, I just wrote an SQL query, and that was it. What's the big deal?

Reply View 3 replies

sceptic123 4 days ago

This depends very much on the size of the code base, the amount of data in the DB and (of course) the quality of the ORM.
It sounds like you are lucky enough that you have never had an ORM generating badly optimised/n+1/over-eager queries that take down a production service. Or perhaps had to debug low level query cache issues causing unexpected problems.
I'm not advocating for plain SQL, just offering some suggestions as to why someone might want you to consider it.

Reply View | 0 replies
alabastervlog 4 days ago

It depends on the ORM. I've definitely seen a couple (popular, even) where it's worse than nothing at all, if you're comfortable in SQL. But most of them I'd agree, they're handy.
I think some of the blanket "just don't" comes from people who've had to onboard to projects written by teams that didn't understand SQL, but did (sort of) know how to use an ORM, and blame the ORM for allowing those teams to commit their atrocities. But that doesn't make an ORM a bad thing in capable hands.

Reply View | 1 reply
- stavros 4 days ago
  
  Ah yeah, my experience is with the Django ORM, with which I've had nothing but good experiences with.
  
  Reply View | 0 replies

ahmedfromtunis 4 days ago

Every one of the three points you made in your comment has been disapproved by Django.

It's a framework that does (or at least tries) to do everything (or as much as possible), and it's good. Really, really good.

I'm in the process of upgrading an app of mine after months of abandonment, and the process is so smooth it's boring.

Also, Django's ORM is the closest thing to a perfect tool. Sure, it has some dark corners here and there, but Django's ORM has considerably improved my quality of life as a programmer. Heck, I even moved from SQLite to PostgreSQL in an old project, and all I needed to do is to change a couple of config code.

Oh, and Django is both stable and enjoys a constant pace of updates adding useful features practically at every major version.

Reply View 2 replies

m4tx 4 days ago

Agreed, and what you mention here are the main reasons Cot has been strongly inspired by Django. Whether we'll achieve the same level of stability and ORM ease-of-use for the Rust-preferring community, only time will tell.

Reply View | 0 replies
iterateoften 4 days ago

Yeah. I can’t believe the alternatives that people try to glue together compared to Django.
Honestly Django has the best db migrations I have used from any language or library.
When I start a project, even if I am going to access the db from raw sql I start by modeling it in Django just because the rapid changes in data modeling allow me to not even think about it. I just have to think about what I want it to be and not about the changes to get there. Other ORMs or no ORM I am writing alter tables instead of focusing on the data model itself.

Reply View | 0 replies

adampwells 3 days ago

I program Rust using the Axum framework and Sqlx.

Github copilot is so good at writing CRUD db queries that it feels as easy as an ORM, but without the baggage, complexity, and the n+1 performance issues.