5 ms·
Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d
by cqqxo4zV46cp 2y ago
Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d done that, that I realised, even though it’s not perfect, how fantastic the Django ORM is. I thought they’d all be that good, but no.
I’ve read a lot of criticisms of ORMs, as I’m sure everyone else has. Some of them are certainly valid criticisms that are immovable and just inherent in what an ORM tries to do. Some of them just seem to be caused by not very many ORMs being good, and the writer not having used one of the better ones.
- 1propionyl 2y agoThis is generally my experience as well. I don't love using ORMs but at least Django's is relatively painless and I can generally find the escape hatch I need. The lack of support until very recently (and it's still lacking) for views is the main knock.
- winrid 2y agoI agree. Django's ORM is great because it handles the relationships well, where many ORMs barely do the object mapping part well. I'm rewriting a large Django project in Java (quarkus + jooq), because it's at the point where I need a type system now, but it still has a place in my heart.
- BarryMilo 2y agoAren't Django models close enough to types?
- wg0 2y agoNope. Python type hinting is far far from Java like types. And yes, I guess OP has now a large system that needs types enforced by the system to reduce the friction in evolving the stack.
- roze_sha 2y agoWhat about using pydantic?
- mehdix 2y agoFWIW, one python project I'm working on uses an obscure Framework, and ORM. I was contemplating to convert it to FastAPI+Pydantic, however the amount of effort needed was no different than rewriting the whole project.
- LtWorf 2y agopydantic + sql database? So have 2 components that ensure the types are correct? Why?
- winrid 2y agoI already use type annotations with Python for use within my IDE. It's just all tiring garbage. Java is already almost a scripting language and I can actually use a shared heap, etc. also I have some core code in java I use in the desktop app I want to reuse in the server. Right now I transpile that core code to TS and then JS to use client side, but I'd rather just have everything in Java.
- Izkata 2y agoIf this is what you're referring to: > Note: The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc. Then yes, Django model definitions are more like Java types in that they error if you try to use an incorrect type. You can't just ignore them like with type hints. They also try to be 1:1 with database types, so for the most part any additional validation added on top of Django would be something you had to do anyway.
- Swizec 2y agoFor me Django and ActiveRecord stand out as 2 good examples of what an ORM should be like. Both feel like they make the simple stuff super easy, the complex stuff figure outable, and the super hard stuff trivially possible with raw SQL and a decent mapping from that back to regular code. Although over the years my code trends more and more towards `.rawSql` or whatever equivalent exists. Even for the simple stuff. It’s just so much easier than first thinking up my query then bending over backwards three times to make it fit into the ORM’s pet syntax. Plus raw sql is so much easier to copypasta between different tools when you’re debugging. And before you say “but sql injection!” – that’s what prepared statements/parametrized queries are for.
- wsc981 2y agoI've started working on a .NET project that uses EntityFramework and due to some of the magic, I prefer just using raw SQL as well. I've used other ORM solutions in the past as well and I am not a fan ... But the team chose EF due to it supposedly being easier to integrate with whatever database the customer might be using and that seems like valid reasoning.
- djeiejejejej 2y agoYes I agree. That’s a valid argument, but there are other ways as well like SQLKata and other query builders. Depending on the complexity of the product I think writing standard SQL92 will get you far as well. I don’t get how an ORM will handle Postgres’ CTEs and windowing functions. Those are pretty basic and extremely useful features to me, but those require dropping to raw SQL. Each vendor has those useful particularities that you immediately lose by going ORM. So in practice you are already required to make your queries as bland as possible where GROUP BY and JOIN is about as complex as it will get. I’d say just do SQL92 work around the limitations - which is something you’ll have to do anyway, but now more directly - and all major vendors will work OOB.
- Izkata 2y ago> I don’t get how an ORM will handle Postgres’ CTEs and windowing functions. Those are pretty basic and extremely useful features to me, but those require dropping to raw SQL. Each vendor has those useful particularities that you immediately lose by going ORM. Django has supported windowing functions since 2.0, almost 7 years ago: https://docs.djangoproject.com/en/2.0/ref/models/expressions/#django.db.models.expressions.Window https://docs.djangoproject.com/en/2.0/ref/models/expressions... And people are experimenting with CTEs - this looks pretty natural to use, at least with the basic example, and it supports recursive CTEs even if the example looks clunky (though I think that's their choice of example rather than the actual recursive part making it look bad): https://dimagi.github.io/django-cte/ https://dimagi.github.io/django-cte/ (repo: https://github.com/dimagi/django-cte https://github.com/dimagi/django-cte)
- choilive 2y agoDjango's ORM is acceptable - but I think Rails/ActiveRecord is superior albeit certainly more opinionated. Most likely just my personal bias speaking because Rails was the first web "framework" I cut my teeth on.
- wg0 2y agoI think Django's ORM is really great but only as long as that's the first thing you have seen. If you started from Rails and ActiveRecord, you're probably not be very appreciative of Django's ORM.
- bitexploder 2y agoSQLAlchemy is the best stand alone ORM I have found.
- baq 2y agosqlalchemy is easily one of the best ORMs ever made for any language. Hats off to zzzeek. Currently working in typescript and writing SQL queries out by hand since I just don’t trust anything to do the right thing wrt units of work.
- JodieBenitez 2y agoI don't know, the declarative API is awkward. I get SQLAlchemy is quality software but I found DX poor.
- greenie_beans 2y agoi've used both. they both have pros/cons. use whatever tool your team is most proficient with/stop wasting your time arguing about which framework is best
- malux85 2y agoI love the django ORM and then the REST framework on top of that. Define the object, hook it to a view, use our custom permission class, done. GET, POST, PATCH, DELETE all urls, filtering, pagination, search, ordering, complex multi-org multi-user object permissions handled automatically. Need custom logic? Just overwrite method. It’s a productivity superpower, sure there’s a lot to learn but that’s the price you pay for the tools that make you hyper productive
- nprateem 2y agoNinja is even better than the REST framework. Practically no boilerplate.
- Izkata 2y agoThe awkward part is realizing Django has been this good for well over a decade. The core design hasn't (ever?) changed. I started using Django on I think version 1.2 or 1.3 in 2011, back when it didn't have database migrations and you had to use a library like South for it. Even then, as an ORM/query language it was apparently better than what other languages have now.
- simonw 2y agoThe design of the ORM changed substantially once, early in Django's history, when the "magic removal branch" landed. There are some notes on the new syntax that introduced here: https://code.djangoproject.com/wiki/RemovingTheMagic#Codechangesyoullneedtomake https://code.djangoproject.com/wiki/RemovingTheMagic#Codecha... That branch merged on May 1st 2006: https://www.djangoproject.com/weblog/2006/may/01/magicremoval/ https://www.djangoproject.com/weblog/2006/may/01/magicremova... I've long found Django's commitment to not breaking too much at once inspiring. The release notes and upgrade guides are really solid.
- vandahm 2y agoI used Django a lot from about 2007 to 2010 and, then, went for several years without using it at all. When I came back to it, I was delighted to find that everything still worked like it was supposed to, just better. Congrats on getting it right on the first try. That's...not something that happens very often in software.
- JodieBenitez 2y ago> I thought they’d all be that good, but no. I had the "pleasure" to use Doctrine once. Never again !
- vandahm 2y agoI used Doctrine for a few years, and I remember thinking that it was about 50% awesome and 50% terrible. I wonder what I would think if I came back to it today.
- murkt 2y agoIn 15+ years I’ve only used two orms: Django ORM and SQLAlchemy. I’ve also skimmed docs for many others (some JS orms, etc), and those often look completely unusable. SQLAlchemy is leagues above and beyond Django ORM. I can’t say I have nightmares from dealing with it, but it certainly was not pleasure. A bit too much magic here and there, not flexible enough and provokes too much bad practices. Re-defining save() methods to do a lot of work, anyone? The best “orm” that I’ve ever used was not an ORM but a query builder — HoneySQL from Clojure. That one is fantastic. No ORM bullshit, no extra data loaded from DB, no accidental N+1 queries. Not reading docs on how to do a GROUP BY, everything’s just easy to write. Frankly, we often use SQLAlchemy as just a query builder too. Makes life so much easier.