--- In firebird-support@yahoogroups.com, "tigereye_philip" wrote:

> Alexander,
>
> While committing some code to CVS tonight I realized I had a
> splendid example of sub-transactions right in front of me. Every
> once in a while I'll have quite a few files checked out of CVS,
> locally modified. I'll find I've made useless changes which I don't
> want to commit back to the repository, because they're trivial. (As
> I usually work on a Borland C++ Builder project, .dfm files very
> often get trivially changed by developpers moving the form around to
> fit their screen resolution. On other days, I just realize I'm being
> a moron and take appropriate action.)
>
> So my solution is to get a "clean copy" of just that one file (or
> set of files.) I don't rollback my entire sandbox (I may be an
> idiot, but there's some hard work I want to keep,) and I don't
> manually undo my changes by applying reversal changes. I effectively
> rollback changes to some files, but not others. I think that
> illustrates sub-transactions, in a sense. (In-as-much as CVS is any
> sort of rigorous transactional system, which it's usually not.) I
> was working on all of them more-or-less simultaneously. Later, I'll
> wish to commit all of these changes (generally) together -- changing
> just a .h file without the .cpp file will likely irritate someone,
> somewhere. That'd be equivalent to committing a top-level
> transaction.
>
> Am I making some sort of sense? Thoughts? (I have a feeling the CVS
> example is actually closer to the split/join semantics: you can do a
> final top-level commit on a subset of the entire sandbox, etc.)

Hmm, cannot this be solved by having one additional table? Let's say
you have your CVS table and one more table TopLevelCommitted. Your
TopLevelCommitted table should just contain one field filled by a
generator and the same field should be in your CVS table as well. As
soon as your 'top level' transaction starts you grab a number from the
generator and for each of your 'sub-transactions' you use this number
with the CVS table (each 'sub-transaction' being a transaction of
their own). At the end, you insert into TopLevelTransaction and
commit.

To select from the CVS table, you always do

SELECT <columns>
FROM CVS
JOIN TopLevelCommitted TLC
ON TLC.GeneratedNumber = CVS.GeneratedNumber
WHERE ...

That way, no-one gets to the changes until your top level transaction
is committed and if it never commits you just have orphan records that
doesn't do more harm than wasting space. This is just a vague
description of a not all to thoroughly thought through idea and
refinements would have to be done to implement it. I'm not advocating
against sub-transactions (I don't know enough about them to have much
of an opinion), just saying that I think your CVS example could be
solved without them.

Set
-I support Firebird, whether or not it has sub-transactions. That's
why I am a member of The Firebird Foundation, which you can join at
http://www.firebirdsql.org/ff/foundation