On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote:
> Peter Jones <pjones@xxxxxxxxxx> writes:
> > Do they support rollbacks after commit? If they don't, they're not
> > really as useful for this as they could be.
> Rollback *after* commit? This must be some other usage of the term
> "commit" than is standard to database people.
No it's just a new definition of "rollback" than is standard. The idea
is that _ideally_ people seem to _want_ to be able to do:
1. update to new foo
2. run random other things that alter data.
3. update to new bar
4. run random other things that alter data.
5. run new foo, which alters it's data.
6. run random other things that alter data.
7. run new bar, which alters it's data.
8. run random other things that alter data.
9a. Decide foo is bad and thus. "rollback" just #1 and #5.
9b. Decide bar is bad and thus. "rollback" just #3 and #7.
...so all solutions tend to be exercises in randomly picking the
features you think they really want, from what is desired.
Yum history assumes you are happy with just #1 and/or #3.
Snapshots assume you are happy to take a lot of collateral damage to
get #5 and/or #7.
James Antill - james@xxxxxxxxxxxxxxxxx
fedora-devel-list mailing list