In Django we get used to a certain pattern of work with ORM (it is called Active Record). Here are a couple of examples.
In this case assignment another_m1.value = 'new-value' didn't modify the m1.value since m1 and another_m1 - different objects in memory. Although they represent the same row in the database with primary_key = 1. In SQLAlchemy it is not the same, as long as we are working with "session": Here m1 and another_m1 - exactly the same object in memory, although we've made two separate queries with ORM. SQLAlchemy remembered that the row with M1.id == 1 was already acquired and didn't even reach the DB in the second request. Therefore, another_m1.value = 'new-value' will change m1.value.
In Django we must keep the ordering of creation of two related objects: In this example we have to save the parent model first: and only then we can save the child. SQLAlchemy is working a little bit differently, it is accumulating operations that must be sent to DB and actually executing them only when it thinks it is time to. And the ordering of the operations it also defines by itself. Here we've created two instances in ORM's memory, first adding a child to the session and then parent. But SQLAlchemy is smart enough to understand that Parent must be saved first to get the primary key of it and only then we can save the child.
[
Collection
]
[
|
...
]