> > > 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" > > I think he means the distinction between actual time and record > time of temporal objects as nicely described by Fowler (http:// > www.martinfowler.com/eaaDev/timeNarrative.html). I'm currently > developing an application that needs that distinction and I can say > that it can get pretty confusing at times. yes, it is. And we found a 3rd dimension, application-field/documents related. Apart of some relations also being bitemporal.. it's all pretty and entangled.
> > > 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). > > If you know really well what you're doing then it may be simpler to > offload all the lock management, transaction isolation and > consistency to the database. But as a rule of thumb, long-running > transactions are bad, mkay. > > > 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. > > Actually unit of work can be regarded as a kind of command pattern. > So what could work here is nested units of work. yes, a sort of. But i need the results of inner UOWs to be query-able, i.e. to see results of the inner (already closed) UOW when issuing some select() within the outer one. So far my decision is to create everything as it would be (optimistic), in short simple transactions, and keep track of what's being created - and erase it if user cancel the outmost transaction. To avoid trouble if erasing fails, i may also add some sort of state-flag "is_temporary" to all those records, so they can be visible within the transaction (flag is True), but not outside - without the flag being cleared. Thus if removing fails, the records will stay without affecting the overall result. (Of course all queries should have additional filter on that flag for this to work.) Do u see any problem with this? hmm.. with this flag i may even not need to keep track of changes - just 'Delete from ... where flag=true...' ciao svil --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
