Hi,
On Sunday, June 2, 2013 5:47:03 PM UTC+1, pub...@enkore.de wrote:
Thanks a lot for your comprehensive answer! I was able to solve my
problem by implementing your first suggestion. Orphans do not play a
role yet� I think :-)
On 06/02/2013 05:09 PM, Michael Bayer wrote:
The only
On Dec 11, 2013, at 8:02 AM, Tim Kersten t...@io41.com wrote:
The before_delete and after_delete shouldn't make use of the current Session
though, according to
http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html?highlight=after_delete#sqlalchemy.orm.events.MapperEvents.after_delete
On 11 Dec 2013, at 16:32, Michael Bayer mike...@zzzcomputing.com wrote:
On Dec 11, 2013, at 8:02 AM, Tim Kersten t...@io41.com wrote:
The before_delete and after_delete shouldn't make use of the current Session
though, according to
When using more complex, hierarchical models with differing settings on
how cascade deletes are handled it gets quite hard to figure out
beforehand what a delete() will exactly do with the database.
I couldn't find any way to get this piece of information (Hey
SQLAlchemy, what will be deleted if
The only deletes that aren't present in session.deleted before the flush are
those that will occur because a particular object is an orphan, and the
objects which would be deleted as a result of a cascade on that orphan.
So without orphans taken into account, session.deleted tells you
I guess the big question is, when are you calling this.
An easy system would be to add a new event flush_plan_complete which will put
you into a flush() right as the full plan has been assembled, but before any
SQL occurs. It could allow you to register more objects for activity, and it
Thanks a lot for your comprehensive answer! I was able to solve my
problem by implementing your first suggestion. Orphans do not play a
role yet… I think :-)
On 06/02/2013 05:09 PM, Michael Bayer wrote:
The only deletes that aren't present in session.deleted before the flush are
those that
