bojanb wrote:
SQLAlchemy's unit of work attempts to set it to
None during the flush.
Doesn't that imply that ondelete='RESTRICT' is not honored by UoW?
how would the UOW honor RESTRICT ? if you tell it to delete a parent,
and you didn't tell it to delete a child, and you have a
On Oct 29, 5:32 pm, Michael Bayer mike...@zzzcomputing.com wrote:
how would the UOW honor RESTRICT ? if you tell it to delete a parent,
and you didn't tell it to delete a child, and you have a non-nullable FK
or RESTRICT, you'd expect it tothrow an error, right ? isn't that
what
bojanb wrote:
On Oct 29, 5:32 pm, Michael Bayer mike...@zzzcomputing.com wrote:
how would the UOW honor RESTRICT ? if you tell it to delete a parent,
and you didn't tell it to delete a child, and you have a non-nullable FK
or RESTRICT, you'd expect it tothrow an error, right ? isn't
Yes, the passive_deletes='all' solves this, the trick is to put it in
the backref (I was putting it in the forward relation).
On Oct 29, 8:29 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Michael Bayer wrote:
bojanbwrote:
On Oct 29, 5:32 pm, Michael Bayer mike...@zzzcomputing.com
bojanb wrote:
I have columns in my database that logically shouldn't be null.
However, I allow them to be null while the user is editing (creating)
objects interactively. As this is done in a transaction, and values
are checked before a commit, it's assured that nobody else ever sees
If I understood correctly, you suggest adding @validates method for
the column that I don't want to be null on commit? That doesn't work
since it wouldn't allow me to store objects with null attributes in
the current transaction.
In fact, @validates is even more restrictive than a non-null
bojanb wrote:
If I understood correctly, you suggest adding @validates method for
the column that I don't want to be null on commit? That doesn't work
since it wouldn't allow me to store objects with null attributes in
the current transaction.
In fact, @validates is even more restrictive
