[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.
[sqlalchemy] 0.8 doc url goes to 0.9 docs
The url I've been using for the 0.8 docs (http://docs.sqlalchemy.org/en/rel_0_8/) now goes to a page listing 0.9 docs. There doesn't seem to be any way to get at 0.8's docs from the website. -- 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] Query and compiled_cache
On Sat, Jun 1, 2013 at 10:59 PM, Michael Bayer mike...@zzzcomputing.comwrote:
The recipe on the wiki also has the issue that it isn't even caching
anything to do with the QueryContext, including all of this information
regarding eager joins which is pretty important. Your modifications try to
correct for this by storing that context, but then it still creates a
brand new context anyway and just transfers not nearly enough of its state
over for things to work.
Yes, I was trying to keep it minimal to figure out why the error up there,
but I did start the way you describe, by storing everything
session-independent from the query context.
So the whole thing is rolled up into the named thing I referred to also,
so that there's no need to keep a Query object hanging around, when we say
bake() we're really just referring to a position in the code somewhere,
so I've updated the wiki recipe to use a named system like this:
q = s.query(Foo).\
filter(Foo.data == bindparam('foo')).\
bake_as(foo, cache)
result = q.params(foo='data 12').all()
A highly cleaned up version of your test is attached.
I'm still not sure I'm getting everything accounted for here! thanks for
testing ! The feature is actually looking quite simple and probably works
better as something built in, or at least if we added some methods to
QueryContext to ease the burden of caching/copying it.
Well, if that works, it certainly covers my needs so there would be no
pressing need to incorporate it into the core.
I'll let you know tomorrow.
--
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] 0.8 doc url goes to 0.9 docs
I cant even tell what the issue is, the rel_0_8 tag is correct in git and readthedocs is supposed to be building that tag. But its checking out master. I'm not sure how to fix this at the moment. On Jun 2, 2013, at 8:34 PM, Jon Rosebaugh chai...@gmail.com wrote: The url I've been using for the 0.8 docs (http://docs.sqlalchemy.org/en/rel_0_8/) now goes to a page listing 0.9 docs. There doesn't seem to be any way to get at 0.8's docs from the website. -- 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] 0.8 doc url goes to 0.9 docs
https://sqlalchemy.readthedocs.org/en/rel_0_8/ actually does seem to have the correct stuff too. On Sunday, June 2, 2013 5:43:34 PM UTC-7, Michael Bayer wrote: I cant even tell what the issue is, the rel_0_8 tag is correct in git and readthedocs is supposed to be building that tag. But its checking out master. I'm not sure how to fix this at the moment. On Jun 2, 2013, at 8:34 PM, Jon Rosebaugh cha...@gmail.com javascript: wrote: The url I've been using for the 0.8 docs ( http://docs.sqlalchemy.org/en/rel_0_8/) now goes to a page listing 0.9 docs. There doesn't seem to be any way to get at 0.8's docs from the website. -- 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+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.comjavascript: . 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] 0.8 doc url goes to 0.9 docs
They wiped everything and it should work now. Sent from my iPhone On Jun 3, 2013, at 12:19 AM, Jon Rosebaugh chai...@gmail.com wrote: https://sqlalchemy.readthedocs.org/en/rel_0_8/ actually does seem to have the correct stuff too. On Sunday, June 2, 2013 5:43:34 PM UTC-7, Michael Bayer wrote: I cant even tell what the issue is, the rel_0_8 tag is correct in git and readthedocs is supposed to be building that tag. But its checking out master. I'm not sure how to fix this at the moment. On Jun 2, 2013, at 8:34 PM, Jon Rosebaugh cha...@gmail.com wrote: The url I've been using for the 0.8 docs (http://docs.sqlalchemy.org/en/rel_0_8/) now goes to a page listing 0.9 docs. There doesn't seem to be any way to get at 0.8's docs from the website. -- 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+...@googlegroups.com. To post to this group, send email to sqlal...@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] Query and compiled_cache
Well, if that works, it certainly covers my needs so there would be no pressing need to incorporate it into the core. I'll let you know tomorrow. It's so straightforward at this point I'm leaning towards some more cleanup and adding to 0.9. I'll probably cache the compiled statements on the QueryContext itself too, and the cache dictionary will be via Session / Sessionmaker. -- 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] Query and compiled_cache
On Mon, Jun 3, 2013 at 1:55 AM, Michael Bayer mike...@zzzcomputing.comwrote: Well, if that works, it certainly covers my needs so there would be no pressing need to incorporate it into the core. I'll let you know tomorrow. It's so straightforward at this point I'm leaning towards some more cleanup and adding to 0.9. I'll probably cache the compiled statements on the QueryContext itself too, and the cache dictionary will be via Session / Sessionmaker. Bear in mind that the use case I'm not only now, but always facing, involves queries in many, different, short-lived sessions. So making it Session-local won't live long enough, unless it can be given to the Sessionmaker itself and have that caching context be shared among all sessions. -- 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.
