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 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. >
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 Book keeping within the one transaction becomes somewhat difficult when those are the only places to catch deletes caused by becoming an orphan. Any suggestions on how one might go about adding book keeping rows with this information to the Session? i.e. Like in the after_delete so that it picks up orphan deletes? > > > > > > > > > On Jun 2, 2013, at 9:46 AM, pub...@enkore.de <javascript:> 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 ) > >> > Cheers, Tim -- 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. For more options, visit https://groups.google.com/groups/opt_out.
