On Sep 25, 2013, at 12:23 PM, Julio César Gázquez <julio_li...@mebamutual.com.ar> wrote:
> Hi. > > I'd like to know what's the recommended approach to keep the state of the > session and the associated objects when session.flush() fails, in order to > being able to fix the cause of the problem and retry the operation. > > For cases with a single object hierarchy, I think using session.merge() to > save a copy of the original object could be sufficient, but in the case of > multiple independent objects being added, deleted and modified, I'm not sure. typically the logic is developed such that for those cases where errors on flush() are expected, that bit of logic runs within a savepoint, e.g. "with session.begin_nested()", and the state necessary to retry the operation is available outside the scope of that operation. As of 0.8, any objects that were not changed within the begin_nested() block will not have their state expired on rollback. The recommendation is to construct the app such that errors on flush are generally never to be expected in the first place (I'm not able to envision how an application can "fix the cause" of a structural error, I'd make the code not make that mistake in the first place), save for concurrency related situations in which case the entire operation from the start is re-run, taking into account the new state that was established concurrently.
signature.asc
Description: Message signed with OpenPGP using GPGMail
