At 4:38 PM -0700 4/5/07, Darren Duncan wrote:
To get this to work would basically involve having additional
journal files, with the original one being for the parent-most
transaction, and with an additional one for each transaction level,
or some such arrangement; the extra ones could have file names like
the original but numeric suffixes indicating the transaction level.
<snip>
Note that to maintain backwards compatability, the original journal
file will still need all pre-change pages written to it too, but
intermediate-level files don't necessarily need this, or it can be
done, as the implementer wishes.
Actually, I will clarify that any "additional" journal files do not
need to be on disk ... said pages could just be in RAM, unless there
are too many of them and they need to spill to disk ... only the
parent-most transaction actually needs a journal file on disk, under
the same circumstances that the current journal needs to be on disk
... before writes to the main SQLite db file are being made.
My more general point is that to support child transactions, the
pager layer would need to be updated to represent N ordered layers of
state for changed pages, where N is the number of nested transactions
(an ordinary SQL statement counting as 1), rather than just
representing 2 layers, current and original.
I believe that this can be done fairly easily, and should be done,
assuming the pager is already well designed and doesn't make certain
assumptions.
Moreover, I don't believe that the addition of this feature should
make the SQLite code base much larger, and it shouldn't cause much of
a performance hit, if any at all.
-- Darren Duncan
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
