21–30 of 85 posts
what'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…
what'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…
I'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.
Earlier quoted context omitted.
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.
Being closer to SQL in my projects meant that it had more footguns than C++ and developers had to know a lot about DB details to not break things.
Could you list some specific examples where things broke because of SQLAlchemy's design?
I'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
The main problem was that the "database" was IBM C-ISAM. Think MySQL MyISAM tables, except don't even dream about SQL, you interact directly with the internal primitives through a C API; when you'r used to SQL it feels like bitbanging in ASM.
The plan:
- Write a Python binding to the C-ISAM library
- Write a subset of the Django ORM from scratch that would use the above behind the scenes; of course it's more limited but whatever's there must behave the same.
- Write any new software using that subset; slowly port over the old code to the new software; of course it can't use _everything_ that one would otherwise use in a normal app; but then again C-ISAM was so constrained that expectations were incredibly limited anyway from the very beginning.
- [much later] pivot! swap out the mock-Django models and drop in the real Django ORM (basically s/from mockdjango import/from django import/g) and hit some mysql/psql/whathaveyou that you've populated with the C-ISAM schema and data
- All the software written is all the merrier and Just Works; the world's your oyster.
This was made possible because the Django ORM is _incredibly simple_: the PoC was done in an afternoon, the hardest part being understanding Python meta classes.
I'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
Fun story: I once worked on a C piece of industrial software that was running on AIX 3.x to 6.x; the goal was to have a nicer (web) status monitoring UI as well as being able to implement stuff in a "safer" language and onboard more people. The main problem was that the "database" was IBM C-ISAM. Think MySQL MyISAM tables, except don't even dream about SQL, you interact directly with the internal primitives through a…
Earlier quoted context omitted.
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.
Being closer to SQL in my projects meant that it had more footguns than C++ and developers had to know a lot about DB details to not break things.
These days I hate working with the ORM because it uses weird abstractions that make your life harder as you try to do more complicated stuff with your data. I had a small bug lately where a queryset would aggregate twice because I filtered an aggregated queryset, and this caused it to aggregate again on top of the previous result. I wouldn't have this bug if I was writing my own SQL, or if I used a query builder instead of an ORM. This is just a small example, I have many more annoying things that will cause me to use SQL directly instead of an ORM for my next project.
I'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 tr…