On May 23, 2007, at 10:53 AM, svilen wrote:
> > so, in UI, i have dialog editor for the Parent object, which has some > direct attributes (name, age, etc), and some list of Children. > Adding a Child to the list, or editing attributes of existing child, > is done in another (dialog) sub-editor. So there are 2 nested user > transactions here - adding/editing a Child, and changing Parent's > data. > There are 2 possible way to go: > - nested, i.e. cancelling parent's editor cancels any changes to > parent including adding or editing children data. As result, cancel > of parent editor means no changes whatsoever my guess is that this is the more expected behavior > - no nesting, i.e. confirming Child editor saves the child-data and > attaches child to parent, and cancelling the Parent editor would not > undo any of these. As result, cancel of parent editor means no > changes of parent attributes but all changes in relations remain and this one is less expected. > - partial no nesting, when cancelling parent results in child data > remain changed, but parent's relation is not changed also not expected > There are cases when no-nesting/partial-no-nesting is preferred way, > but there are cases when nesting is required. *shrug* > > add on top of this versioning/bitemporalism and things get tough... big words again...hold on...zero google hits for 'bitemporalism'...OK i guess that means "two things happening at once" > > Any ideas/patterns how to transfer this nesting-of-user-transactions > into DB / alchemy? I dont have a deep insight since i havent done persistent GUI stuff since the late 90s, but definitely dont use a real DB transaction for the dialog windows...you dont want any long-running DB transactions (but i think you knew that). the two options that come to mind, for the nested scenarios particularly, are using multiple Sessions / copies of the objects to keep their changes separate, and the other is to have a separate model configured for your GUI windows...probably a command pattern that encapsulates each click/state change in a distinct command instance (without modifying domain objects). when youre ready to actually write to the database, you loop through your accumulated command objects and apply each change to the appropriate domain object and then flush() as approrpriate. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
