Standalon Django ORM

155 views
Skip to first unread message

Yonas

unread,
Dec 11, 2022, 11:06:58 AM12/11/22
to Django developers (Contributions to Django itself)
Hi,

Given the small number of Django ORM maintainers, making the ORM standalone will, among other things, increase the adoption of Django and bring in new maintainers.

An ORM inspired by Django ORM with over 3000+ stars: https://github.com/tortoise/tortoise-orm




Jörg Breitbart

unread,
Dec 12, 2022, 7:07:50 AM12/12/22
to django-d...@googlegroups.com
I tend to believe the opposite is true. Django was/is a successor in its
field, because it offers an "out-of-the-box" or "batteries included"
experience. Subsequently parts were shaped as needed for that bigger
picture, e.g. the ORM became what it is today.

Does anyone still remember django versions with external south
migrations? Was much more tricky to get done right, ppl would just
forget it, do it in wrong order, whatsoever. Got basically fixed by the
tighter integration with typical django project lifecycling.

By making the ORM an external lib with its own progression and
versioning you'd reintroduce all that fuzz again, plus frictions from
API changes, that seem logical from a db maintainer viewpoint, but make
life harder at consumer end (would be django here). By keeping it in one
place those tiny viewpoint differences can be leveled out upfront.

Ofc mammoths move slower, but they are also more resilient against
disturbance. In terms of good long term maintainability the more
granular/agile approach as seen in the JS-world still has to prove
itself. Projects there need a lot more care&love of their dependency
lists, and typically wont run anymore after 1-2 years without manually
fixing this or that, because package xy of 100+ dependencies turned its
API upside-down for no good reason.

So no, outsourcing things is not always a good idea.
All imho, ofc.

Cheers,
Jörg

Vasanth Mohan

unread,
Dec 13, 2022, 4:31:29 AM12/13/22
to Django developers (Contributions to Django itself)
I second Jörg about better maintainability with tighter integrations.

However, for the fun of stirring the pot, what's the opinion on letting Django define an API for the ORM and letting a library deal with the DB-specific implementation that generates the SQL for query?  Django could have a list of officially supported DBs ('django.db.postgres') to be included in the INSTALLED_APPS to select the DB to be used.

Meanwhile, the community can come up with support for other DBs like CockroachDB, Mongo etc. (just an idea borrowed off the rust community). It can even allow adding additional filters/commands specific to the DB.

Vaz

Carlton Gibson

unread,
Dec 13, 2022, 4:59:00 AM12/13/22
to django-d...@googlegroups.com
I think we already have this no? 


--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d405433e-3ce4-4737-9539-47012a405b9en%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages