On Nov 10, 2007, at 11:05 AM, Nebur wrote:
> > Obviously I've used a very basic feature (rollback) without knowing > exactly what it does. Even RTFM didn't clearify all. > ----------------------------------- > > Problem: Using the ORM, we delete an object x. > Since another object (y) is referencing x, SA clears out the > ForeignKey in y pointing to x (UPDATE y SET x_id=NULL WHERE ...) > But the UPDATE fails. We catch it and rollback the transaction. > > Any following flush() will repeat the UPDATE (and fail again forever). > Obviously, rollback did not bring the Session in the state it had > before the transaction. > > Currently, my only solution is to combine Session.rollback() with > Session.clear(). > The application obviously cannot lean back and enjoy the rollback() > doing all the work. After clear(), the previous Session state has to > be restored, resulting in a plenty of preventive save_or_update() > calls. > > -- -> Am I right that rollback() does not restore a Sessions pre- > transactional state ? Is rollback() followed by Session.clear() the > best solution ? you're correct. There have been some attempts at having Session do more on a rollback, for example rolling back the attributes of objects to their "committed state". but that is only a small percentage of the total "state" of the session. Whether a session rollback should also remove instances that were added since the last begin() is an ambiguous netherworld (note that this would be different from a clear()) and theres other decisions that would be very difficult to make (and would require much more complexity just to track). On top of all that would be the fact that an application which encounters an error that rolls back the transaction would then have no way to inspect the Session to gain more information about what went wrong, even something as simple as "username already exists: 'foo'" would be impossible because the string "foo" might have been rolled back. So overall a Session which tries to roll back its in-memory state would lead to many unwelcome surprises. therefore the recommendation is that you usually want to clear() or close() a Session after a rollback; the "rollback" only affects the transactional state on the database connection itself, not any ORM objects. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
