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
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
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
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
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
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
