Overall for SQLAlchemy to know that it has to remove a row from an association
table, it has to know that an object on one side or the other is being deleted.
if the linkages here are somehow going from that CASCADE you have to a row
that then does not have a CASCADE, and SQLAlchemy doesn't h
It's still a little bit long because you need the many to many
relationships off chain to at least variable_region, but I can send that if
the below doesn't clear things up for you:
I finally got it to work by updating the "business logic" script that (at
least from my current analysis and testing
On Wed, Apr 14, 2021, at 11:45 AM, Mark Aquino wrote:
> Thanks. I’ll take a stab at this approach. To back up a little bit my main
> confusion is around why the association tables aren’t updating as expected.
> As I understand it, without cascades configured, the default behavior should
> be t
Thanks. I'll take a stab at this approach. To back up a little bit my main
confusion is around why the association tables aren't updating as expected. As
I understand it, without cascades configured, the default behavior should be to
remove associations from those tables. If I configure cascades
Thanks. That worked, too.
On Tuesday, April 13, 2021 at 8:46:34 AM UTC-5 Mike Bayer wrote:
> the next section at
> https://docs.sqlalchemy.org/en/14/orm/mapping_columns.html#automating-column-naming-schemes-from-reflected-tables
>
> shows how to automate intercepting of reflected columns, so
hey there-
The general strategy, if you want to write business logic that checks things,
takes other actions, etc. when changes occur in the session, is to use the
before_flush event handler:
https://docs.sqlalchemy.org/en/14/orm/events.html?highlight=before_flush#sqlalchemy.orm.SessionEvents
