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 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.
