yes, do a flush() after removing the old object before applying the new one.
On Fri, Feb 4, 2022, at 2:17 AM, Dane K Barney wrote:
> Thanks for the explanation, Mike. That makes sense and now I know about this
> behaviour.
>
> > you can get your test program to succeed by sending name=None for
Thanks for the explanation, Mike. That makes sense and now I know about
this behaviour.
> you can get your test program to succeed by sending name=None for the
second B():
I realize my example was pretty trivial, but suppose in a real-world
example where table B did not simply have the column
this is the long-expected behavior of the unit of work when issuing a delete()
and then an add() of two different objects that nonetheless have the same
primary key value - instead of DELETE and INSERT, you get an UPDATE. the
reasons have to do with the unit-of-work's ordering of
I have two tables, A and B, that have a one-to-one relationship. Because of
this, table B uses the same column as its primary key and the foreign key
to table A.
For some reason, trying to delete and replace an object of table B is not
working as expected. Here is a complete runnable example
