Django: One ORM to rule all databases
paulox.net
Django: One ORM to rule all databases
1–10 of 85 posts
Re: Django: One ORM to rule all databases
#2I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
Re: Django: One ORM to rule all databases
#3I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
SQLAlchemy was just more expressive in previous years and was a requirement for projects that had more advanced data types and didn't want to use raw sql (or build their own ORM pieces).
Django is sealing its fate with the opposition to type annotations. I hope sqlc continues to grow on the Python side because it is wonderful in Go.
alembic is also much better than Django's migrations for the ability to expose the tree like structure with operation commands to manage it.
If Django would add some concept of project level migrations I would be much happier. When I build internal software I prefer one app to rule the domains so I have one set of migration history to manage. But everyone leans extra hard into over packaging into Django apps as a mechanism for name spacing domains and then cross app references / foreign keys make long term migration management a giant pain.
Re: Django: One ORM to rule all databases
#4I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
I prefer working with Django ORM too by a large margin. But I think it's more opiniated than SQLAlchemy, which may be why SQLAlchemy is considered the reference (well.... this and the fact that Django ORM is not a standalone lib). It's great if your use case fits to it but if not, SQLAlchemy probably gives you more adaptability.
But yes, Django ORM any day... or just no ORM at all.
Re: Django: One ORM to rule all databases
#5I'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
But why? Although I have way more experience with Django ORM, I find that SQLAlchemy is closer to SQL and I have to think less how to express complex queries. With Django ORM changing a few characters can change resulting query from LEFT JOIN to INNER JOIN, for example. I find it more difficult to write complex queries in Django ORM.
Re: Django: One ORM to rule all databases
#6Sad not to see SQL Server listed, if only because my first ever open source contribution was a patch to that driver for Django around 0.96 (the Internet seems to have no memory of it). I guess it’s not surprising as the fix was simply to correct a typo in the word “python” IIRC, so that spoke to the level of love it was going to see.
SQL Server was the only “real” database available to me at work at the time.
Re: Django: One ORM to rule all databases
#7what's the purpose of this blog post?
"My goal is to help you see quickly where each database works well and where it has some limits. I also hope this can be useful for anyone who wants to improve Django, or just understand it better."
OK, then I look at the feature matrix and see a lot of obvious errors, then I see:
"The data in the table below is entirely fictional and intentionally provided only for example! I included these features just to show what the final matrix could look like, to help start a discussion in the community. Do not use them for any real analysis or decisions."
OK...so....we'll come back when you've written it? What are we looking at?
Re: Django: One ORM to rule all databases
#8what's the purpose of this blog post? "My goal is to help you see quickly where each database works well and where it has some limits. I also hope this can be useful for anyone who wants to improve Django, or just understand it better." OK, then I look at the feature matrix and see a lot of obvious errors, then I see: "The data in the table below is entirely fictional and intentionally provided only for example! I in…
Last night I was on a SaaS pricing page that said that some of the info on the page was generated by AI and might be inaccurate. On a static sales page? Who'd do business with an entity that can't be bothered to write its own pricing info, or at least proofread it to the point of not needing the disclaimer?
Don't know if AI had anything to do with this but what you quoted reminded me of it.
Re: Django: One ORM to rule all databases
#9Sad not to see SQL Server listed, if only because my first ever open source contribution was a patch to that driver for Django around 0.96 (the Internet seems to have no memory of it). I guess it’s not surprising as the fix was simply to correct a typo in the word “python” IIRC, so that spoke to the level of love it was going to see. SQL Server was the only “real” database available to me at work at the time.
SQL Server is actually supported in Django with this backend by microsoft https://github.com/microsoft/mssql-django
Re: Django: One ORM to rule all databases
#10Is Django's ORM even supported outside Django sites?
I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.