Ramon Ribó wrote:
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.
Ramon,
In order to insert any data into an sqlite database you have to have it
in memory in some intermediate data structure. All I have suggested is
querying the user before you do the insert instead of after, so that you
don' t need to undo the insert if the user does not want that data inserted.
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.
I fully agree. I just think its important to point out that the range of
problems that require nested transactions is not nearly as large as
people assume when they first start thinking about the issue.
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.
That is not what I'm saying. There is no requirement to know the all the
steps that will be included in the transaction or the order of
performing them before the transaction begins.
The point of a transaction is that all the actions are done or none are.
The individual actions can be conditional, or done in different orders
from one transaction to another. What you don't want to do is include
any action that is not necessary to the successful completion of the
transaction. This way if an error occurs at some point, the transaction
can be rolled back to undo all the changes in the same way the database
handles an incomplete transaction due to a catastrophic failure such as
a power failure. If the transaction only includes necessary statements,
then an error in any statement means the transaction is incomplete, and
therefore should be completely undone.
If you include unnecessary actions in your transaction, you are not
using transactions correctly, and you will run into problems.
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.
Again, I agree fully.
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
