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 everything
that is to be deleted.
To take orphans into account requires traversing through all the relationships
as the unit of work does, looking for objects that are currently orphans
(there's an API function that will tell you this - if the object is considered
an "orphan" by any attribute that refers to it with delete-orphan cascade, it's
considered an "orphan"), and then traversing through the relationships of those
orphans, considering them to be marked as "deleted", and then doing all the
rules again for those newly-deleted objects.
The system right now is implemented by orm/dependency.py. It is probably not
hard to literally run a unit of work process across the session normally, but
just not emit the SQL, this would give you the final flush plan. But this is
an expensive process that I wouldn't want to be calling all the time.
A feature add is difficult here because the use case is not clear. Knowing
what will be deleted basically requires half the flush process actually
proceed. But you can already implement events inside the flush process
itself, most directly the before_delete() and after_delete() events that will
guaranteed catch everything. So the rationale for a new feature that
basically runs half the flush, before you just do the flush anyway and could
just put events inside of it, isn't clear.
On Jun 2, 2013, at 9:46 AM, pub...@enkore.de wrote:
> 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 I delete that object over there?")
> from SQLAlchemy. Implementing this by myself doesn't really seem like an
> option since this would result sooner or later in situations where my
> prediction and the actual consequences of the delete() differ, which
> would be very… unpleasant for the user.
>
> (This question was also posted on SO:
> http://stackoverflow.com/q/16875605/675646 )
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+unsubscr...@googlegroups.com.
> To post to this group, send email to sqlalchemy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
