Hi, On Feb 1, 2013, at 5:36 PM, Michael Bayer <[email protected]> wrote:
> OK, had to think a bit for how this should be done. Thanks for picking this up, Mike! I looked through your patch and I wondered about a few more conditions: should an object also be expired the moment I mark it for deletion? The actual scenario in my application is a little more complex than what my original snippet has shown: it uses a chain of references (Nodes having NICs having IPAddresses). Deleting a Node already triggers the cascades correctly and the NICs as well as the IPAddresses get marked for deletion and are deleted from the DB. Now, when, during a single transaction, I want to delete a Node and then reassign the IPAddress, my application asks the IPAddress whether it has a back reference to a NIC. What happens then depends on application behaviour: * the app queries for the Address to be assigned again, gets no result and creates a new object. This works fine. * the app still holds a reference (there are scenarios in my application where this makes the code more db agnostic) and uses that object to assign it to a new NIC The latter case will currently fail because, although marked for deletion, the objects still have all of their state, including working references. So … what's your take on that? :) Christian -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
