Chris Withers wrote:
Jim Fulton wrote:
Chris Withers wrote:
Jim Fulton wrote:
Even if you did track reads, how would you distinguish an "unsafe"
read as above from a "normal" read that shouldn't cause a conflict?
A write (or the undo of a write) would conflict with any reads in later
tra
Jim Fulton wrote:
Chris Withers wrote:
Jim Fulton wrote:
Even if you did track reads, how would you distinguish an "unsafe"
read as above from a "normal" read that shouldn't cause a conflict?
A write (or the undo of a write) would conflict with any reads in later
transactions.
Wouldn't tha
Chris Withers wrote:
Jim Fulton wrote:
...
Even if you did track reads, how would you distinguish an "unsafe" read
as above from a "normal" read that shouldn't cause a conflict?
A write (or the undo of a write) would conflict with any reads in later
transactions.
Jim
--
Jim Fulton
Jim Fulton wrote:
Logical inconsistencies. Consider two transactions, T1
and T2 that run the same code:
def f():
if 'x' not in somefolder:
somefolder['x'] = 42
The postcondition of the transaction is that somefolder
has an item named 'x' with the value 42.
Now, when T2 runs,
On May 17, 2006, at 6:54 AM, Jim Fulton wrote:
It was claimed earlier in this thread, that plone only lets you
undo the
most recent transactions. If this is true, then that should not be
a problem. A facility that let you only undo "last" transactions
would be safe. It would also be useful
Chris Withers wrote:
Hi Jim,
Jim Fulton wrote:
BTW, I strongly discourage use of Undo except in emergencies.
Sadly, except when undoing the last (non-undo) transactions in
a database can lead to inconsistency.
What sort of inconsistencies are you referring to?
Logical inconsistencies. Co
And undo is prominently exposed in Plone, and its use is not discouraged.Do you think, Jim, that we should reconsider that?--rOn 17 May 2006, at 08:18, Chris Withers wrote:Hi Jim,Jim Fulton wrote: BTW, I strongly discourage use of Undo except in emergencies.Sadly, except when undoing the last (non-
Hi Jim,
Jim Fulton wrote:
BTW, I strongly discourage use of Undo except in emergencies.
Sadly, except when undoing the last (non-undo) transactions in
a database can lead to inconsistency.
What sort of inconsistencies are you referring to?
Undo can be a very attractive feature although usuall
Hi Jim. I managed to fix this by modifying the storage but it seems to
me strange to differentiate in a storage whether it is a backend to a z2
or z3 app.
Regards,
David
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis
Jim Fulton wrote:
David Pratt wrote:
There seems to be enough of a difference between Z2 and Z3 undo to
have an effect on a backend like PGStorage from working on Z3. I
believe the objective in the storage api is that it should not matter
to the backend whether you are connected to Z2 or Z3. C
David Pratt wrote:
There seems to be enough of a difference between Z2 and Z3 undo to have
an effect on a backend like PGStorage from working on Z3. I believe the
objective in the storage api is that it should not matter to the backend
whether you are connected to Z2 or Z3. Can someone more fam
There seems to be enough of a difference between Z2 and Z3 undo to have
an effect on a backend like PGStorage from working on Z3. I believe the
objective in the storage api is that it should not matter to the backend
whether you are connected to Z2 or Z3. Can someone more familiar with
the hist
12 matches
Mail list logo
