Hacker News Reader

Comment by Onavo | Hacker News Reader

The most powerful part of Django is its ORM, nothing else comes close in the ecosystem. The automatic migration generation tools for SQLAlchemy like alembic are much harder to use than django's built-ins.

Django just needs to add Pydantic integration.

View on HN

In what way "most powerful"? If you do anything more involved than CRUD it falls apart pretty fast. You can't express most of the things you can do with raw SQL since there is not intermediate DSL like you do with SQLA. You can't hydrate arbitrary object graphs. It's slow, for deep queries building back objects is slower than actual SQL round trip.

It's very easy to use but it's also very limited and i often find myself dropping down to RawSQL or even having SQLA connection in my Django projects.

Then you might not be in the target audience of Django. For the rest of us, the ORM is dope as hell and nobody cares that you aren't writing the most performant SQL the world has ever seen...

The ORM is fantastic and I never use raw SQL, but I can see how it may be simpler to just go straight to raw SQL with complicated database structures and queries.

The best part about it though is that you can use raw SQL and the ORM at the same time. In larger projects that's how I've always used it. ORM for the majority of use cases, and the raw SQL where performance really matters.

Which other Python based ORM addresses those issues?

SQLAlchemy does. I get that DjangoORM is more convenient and might be good enough. But powerful seems like wrong adjective.

Powerful in terms of productivity. The occasional N+1 query problem here and there isn't a big issue for many projects and means you can launch 10x faster than someone using some other technologies. If you're successful, you can easily write raw SQL and optimize as needed.

DjangoORM isn’t perfect but its power comes from the fact it is heavily integrated with Django (the framework).

Ah, sorry. It wasn't clear that SQLA meant SQLAlchemy in your first comment.

I have a few projects where I use Django just for the ORM. The rest of the project is is CLI commands that are being run as Django's management commands to be able to access the ORM models. SQLAlchemy and alembic are quite far behind compared to Django.

There are couple of projects aiming to integrate django & pydantic: https://django-ninja.dev for APIs & https://github.com/jordaneremieff/djantic for model data

Wow, django-ninja is just what I was looking for. Thanks for pointing it out. Here’s their CRUD example: https://django-ninja.dev/tutorial/other/crud/

Few things I want more than for someone to extract the Django ORM from Django so we can use it standalone instead of SQLAlchemy

You can just use it though. There is no need to extract it.

The migrations commands and configs are all tied to manage.py, hard to use without setting up the full boilerplate.

It's not really tied to manage.py no. And in any case that's a trivial 3 lines of code (plus imports, blank lines: https://github.com/iommirocks/iommi/blob/master/examples/man...).

I think you're overdramatizing 3 lines of code...

Have you heard of Tortoise ORM? https://tortoise.github.io/

Have you taken a look at Masonite Framework's ORM [0]? It's an implementation of ActiveRecord. I'm not sure why the framework [1] doesn't get enough attention though. I think it's a nice option for projects that have outgrown Flask but aren't keen on Django.

[0] https://orm.masoniteproject.com/

[1] https://docs.masoniteproject.com/

I was thinking the same the past few days.

Going with fastapi and sqlalchemy, there is no django admin and no user management out of the box.

But writing serialisers for DRF feels dated.

Would highly recommend you check out Django Ninja as well as Django Ninja Extras. Having done Flask + FastAPI dev then Django, Django Ninja brings the modern feel of FastAPI to the battle tested reliability of Django.

I’ve been very happy with Django ninja. It brings in pydantic as well so you get the benefit of type safety in addition to a much faster request response cycle as compared to DRF

You can quite easily generate typescript models from DRF serializers, that helps a lot when setting up a frontend project against a DRF api.

Agree, I never felt comfortable with sqlalchemy, but I don’t need most other django features and find mTLS elf wrestling against them

I'm using Orator as a replacement and enjoying the experience.

Reply on news.ycombinator.com