Dennis,
I cannot agree here. Just imagine that the user decision is based on the
imported data.
Of course, you can read the data of the file, store in temporal structures
on memory, ask
the user and then, enter the data into the database. But the advantage of
using sqlite as
storage mechanism, as drh pointed out, is to use it as file format, an
avoid creating
intermediate data structures.
My opinion is that it is completely possible to live without nested
transactions, in
fact we all do now and survive, but they are very convenient to solve a
full range of
problems. You are right that a different range of problems can be easily
solved by just
maintaining a counter of transactions.
Written in an abstract form, you base your reasoning on the fact that
you know, before
beginning the first transaction, all the future steps that you are going
to perform and
the order of performing them. This is not always true, as some decisions
can be based on
external input, like an interative user, data coming from an external
source, other types
of events. Also, the decision is often taken based on the data itself, so
it is more
convenient to put the data in the database, operate with it and decide
after operation.
Finally, I am not advocating to include nested transactions into sqlite
or not, as this
is a problem to be solved by the people who is developing the library. But
it is important
to include all the facts in the discussion.
Best regards,
--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com [EMAIL PROTECTED]
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46
En Thu, 12 Apr 2007 00:37:21 +0200, Dennis Cote <[EMAIL PROTECTED]>
escribió:
Ramon Ribó wrote:
Imagine one application that can import data from a file. You want
that, in case of computer crash, either all the data of the file is
imported or none. At the same time, you want the user to manually
accept or reject every section of the file.
This example can be modelled in a very natural way with a transaction
covering the full file import and a nested transaction covering every
section.
Ramon,
I don't see that where nested transactions are needed for this example.
You seem to be suggesting a loop reading each file section and writing
it into the database in a nested transaction and then rolling back a
nested transaction if the user says they want to skip that section.
begin
for each section in file {
read section
begin nested
insert section
if promp_user(section) == keep
commit nested else
rollback nested
}
commit
The same thing can be done far more efficiently by prompting the user
first and only inserting the sections the user wants to keep.
begin
for each section in file {
read section
if promp_user(section) == keep
insert section
}
commit
If the program completes all users selected sections are inserted into
the database atomically. If the program crashes the entire file will be
deleted when the incomplete transaction is rolled back. Similarly if an
I/O error occur when reading the file or a disk full condition happens
when inserting a section, those and any other errors would cause the
transaction to be rolled back so that none of the file sections are
inserted. I want to insert all of the user selected sections or none of
them.
Nested transaction only create more work and make the application more
complicated.
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com [EMAIL PROTECTED]
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
