[skrtskrt]

I have run into this exact problem. A many-to-many table had a business meaning, not just an "invisible" relationship. We wanted to put a model in front of it & add soft deletes and created-at/updated-at fields, at it was a mess of hoops and hacks to jump through.

[rrmm]

Does this go easier in any other ORM/DBs that you might have used? Sounds like the semantics of the real-world stuff didn't quite match up to the DB semantics.

[skrtskrt]

We rolled a simple repository pattern library that fit over the SQLAlchemy Table API (no ORM objects, only tables).

Actually writing the the tables was very freeing, no more separation and surprises in the translation between a single model and the multiple tables it can create.

For each new object, we wrote a SQLAlchemy Table object, a domain entity object, and optionally an adapter if you need to map field names between the two. The 300 lines of repo library code did the rest.

A little boilerplate, but no need for a ton of impenetrable, hyper-dynamic ORM code.

Alembic can autogenerate migrations from the SQLALchemy Table objects