[sqlalchemy] Re: #446: Two deletions cascading to the same object can result in an error
Finally, note that I'm _not_ asking for sqlalchemy to maintain the collections for me. All I'm asking is for the cascade code not to attempt to delete objects that have already been deleted and flushed, or at least to safely handle the exception it raises when it does. OK, what behavior are you looking for ? it raises an exception right now. whats unsafe about it ? Well, it interrupts the cascading and leaves session.deleted in an inconsistent state where not all of the object's dependents may be included. I was under the assumption that this meant those dependents wouldn't be deleted, which would be a nightmare for trying to handle the exception. But it seems I was mistaken about that -- the flush finds and deletes the remaining dependents anyway. I could argue that leaving session.deleted in an inconsistent state is still a bad thing, but it's not nearly as severe as I had thought. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: #446: Two deletions cascading to the same object can result in an error
On Jan 30, 12:51 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Jan 30, 2:35 pm, Ian Kelly [EMAIL PROTECTED] wrote: Finally, note that I'm _not_ asking for sqlalchemy to maintain the collections for me. All I'm asking is for the cascade code not to attempt to delete objects that have already been deleted and flushed, or at least to safely handle the exception it raises when it does. OK, what behavior are you looking for ? it raises an exception right now. whats unsafe about it ? Well, it interrupts the cascading and leaves session.deleted in an inconsistent state where not all of the object's dependents may be included. if that were true, thats a bug. can you illustrate this ? the deleted collection on the unit of work is never altered in any way until a flush() completes successfully. in theory, the state of your program after an unsuccessful flush should be identical to that of before the flush. this is one advantage to SA's we dont change your structures approach - not only is it a huge beast to manage the altering of structures, but we'd have to be able to roll the whole thing back too. This happens as a result of a failed session.delete() operation. The flush itself appears to be fine. If you still want an example, I can whip one up. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: #446: Two deletions cascading to the same object can result in an error
On Jan 30, 2007, at 5:26 PM, Ian wrote: the changed state on your objects is stored in an attribute on the object itself called _state (and actually, its not the changes as much as what was loaded from the database). you can freely move instances from one session to the next (using either save_or_update() or merge()) and the changes will be maintained. Okay, that doesn't sound so bad. It looks like I would still have to track deletions myself, but that shouldn't be too much extra work. if you use cascades to maintain your deletes, i.e. you delete an instance by using the delete-orphan cascade and removal from its parent collection, that can also be moved across sessions. I just clarified the description of the detached state in the docs on the site. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: #446: Two deletions cascading to the same object can result in an error
On Jan 29, 8:19 pm, Ian Kelly [EMAIL PROTECTED] wrote: I can live with this response, but I still consider it a bug. If I have to manually remove the instances whenever I delete an object where this exception is possible, then I might as well just be doing the entire cascade for the affected relation manually -- it's essentially the same logic. In fact, that's what I ended up resorting to in my workaround for this (although please let me know if there's a better way). I have a small paragraph about this in the session docs (notes on flush) , the basic idea is that SA in almost all cases will never manipulate any portion of the composition of your objects in memory. the one exception to this is backreferences, which is a feature that takes place almost entirely separate from all the unit-of-work flush logic. for SA to start handling more than that would be out of the scope of SA's main job of mapping objects to tables and issuing SQL..it would become its own object-oriented frameworkthe level of magical behavior observed would be overwhelming to produce, maintain, and document. SA also takes a lot of cues from Hibernate which simlarly would never have anything to do with manipulating collections automatically...Hibernate also makes you write your own bi-directional relationships manually. its unusual in the first place that you have an object which is the target of more than one cascading delete operation...most database designs usually have singular parent/child relationships, or if a single parent has many kinds of child types associated with it, then delete operations usually begin with that parent and then cascade to the children. Finally, note that I'm _not_ asking for sqlalchemy to maintain the collections for me. All I'm asking is for the cascade code not to attempt to delete objects that have already been deleted and flushed, or at least to safely handle the exception it raises when it does. OK, what behavior are you looking for ? it raises an exception right now. whats unsafe about it ? At least in my particular application, I'm willing to live with the collections being inaccurate. silent failure is definitely not an option here...SA aims to be as explicit as possible, not just because its a central Python tenet but its just good programming practice. Hibernate is a lot less friendly in this area too. The problem is that the cascade code is not so willing. The thing that strikes me as odd about this state of affairs is that sqlalchemy potentially ends up forcing upon me the same overhead that the policy is intended to avoid. the cascade behavior is very closely modeled to Hibernate, which I take as close to a best practice as I am currently aware. not that SA cant go beyond what it does, but each step beyond must be considered alot more carefully since its uncharted territorypoorly considered features and only partially-complete functionalities become disastrous, which is why i usually try to not go there without a full plan to implement something in its entirety. and this one, every time it comes up, just sounds like it would need to become an entire in-memory object management system, not something im up for creating right now (and would not be core SA anyway). so in this case, I dont see any core behavior to be built here since my gut says it would be fundamentally incomplete and only create more confusion, but perhaps some Wiki recipies or extensions can help users out. if you want to post some of your common use cases maybe some of those patterns can be fleshed out. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
