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
would then rerun the flush plan to consider any new changes (since that's how
it works right now anyway). How this registration would proceed is tricky,
since it would be nice to use the Session normally there, but that makes this
more complicated to implement. But then it could iterate again through the
new changes and find any remaining steps to take before proceeding normally.
On Jun 2, 2013, at 11:09 AM, Michael Bayer <mike...@zzzcomputing.com> 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.
>>
>>
>
> --
> 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.
