[sqlalchemy] Re: pattern about nested transactions?

2007-05-28 Thread sdobrev
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

[sqlalchemy] Re: pattern about nested transactions?

2007-05-28 Thread Michael Bayer
On May 28, 2007, at 3:33 AM, [EMAIL PROTECTED] wrote: 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

[sqlalchemy] Re: pattern about nested transactions?

2007-05-28 Thread sdobrev
On Monday 28 May 2007 23:43:37 Michael Bayer wrote: On May 28, 2007, at 3:33 AM, [EMAIL PROTECTED] wrote: 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

[sqlalchemy] Re: pattern about nested transactions?

2007-05-24 Thread Ants Aasma
On May 23, 6:44 pm, Michael Bayer [EMAIL PROTECTED] wrote: 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

[sqlalchemy] Re: pattern about nested transactions?

2007-05-23 Thread Rick Morrison
Isn't this the very thing that the session / UOW constructs are supposed to address for case #1? This can all break in a web application that doesn't want to maintain any in-memory state at all -- for those you can serialize via pickle/JSON/whatever the objects being manipulated and hold them in

[sqlalchemy] Re: pattern about nested transactions?

2007-05-23 Thread svilen
On Wednesday 23 May 2007 18:18:42 Rick Morrison wrote: Isn't this the very thing that the session / UOW constructs are supposed to address for case #1? This can all break in a web application that doesn't want to maintain any in-memory state at all -- for those you can serialize via