Re: [sqlalchemy] Find out what's going to be deleted
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.
Re: [sqlalchemy] Find out what's going to be deleted
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 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? you can make use of the Session within the mapper-level events, you just can’t rely upon any actual changes you make to that Session actually being acted upon within the flush, as the flush plan has already been determined at that point. In fact logic was added in recent months that will cause the Session to flush again if events have dirtied up the session within the flush, so these warnings are already becoming too strong for what the current reality is - I would like to dial them back a bit, although this would require nailing down exactly what cases still won’t work as expected. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [sqlalchemy] Find out what's going to be deleted
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 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? you can make use of the Session within the mapper-level events, you just can’t rely upon any actual changes you make to that Session actually being acted upon within the flush, as the flush plan has already been determined at that point.In fact logic was added in recent months that will cause the Session to flush again if events have dirtied up the session within the flush, so these warnings are already becoming too strong for what the current reality is - I would like to dial them back a bit, although this would require nailing down exactly what cases still won’t work as expected. Excellent, thanks. -- 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.
[sqlalchemy] Find out what's going to be deleted
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.
Re: [sqlalchemy] Find out what's going to be deleted
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.
Re: [sqlalchemy] Find out what's going to be deleted
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.
Re: [sqlalchemy] Find out what's going to be deleted
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.
