1. 5
  1.  

  2. 2
    1. 2

      This makes me appreciate how spoiled I’ve been by SQLAlchemy. For example, OP’s Bug 1 is obviated by the fact that the equivalent code using SQLAlchemy is smart enough to only emit an update for the fields that actually change, as you can see in this example I put together (Although I think passing the object is probably a better design in any case). It’s totally possible I screwed something up there and I’m making an unfair comparison; I’m not very familiar with the Django ORM. Please let me know if so!

      Many of the others still affect code using SQLAlchemy, but to my mind they have more to do with understanding and properly using transaction isolation levels rather than the ORM per se.