Eduardo <[EMAIL PROTECTED]> wrote:
Isn't better lock the database while a transaction that can make a
SQLITE_SCHEMA error, as is done with writes? A change in database is
always a change. Also that way you don't waste time in rerunning the
affected transactions.
It is indeed locked as you describe. The problem is as follows:
1. One db handle performs sqlite3_prepare. This does not in itself start
a transaction, but the resulting data structure (the prepared statement)
relies on details of the schema at the time of prepare. E.g. "select * "
query captures the list of columns when the statement is prepared.
2. Another db handle performs a transaction that modifies the schema.
3. sqlite3_step is called on the statement prepared at #1. It is at this
point that the schema modification is discovered. Currently, SQLite
reports SQLITE_SCHEMA error in this situation. The proprosal is for the
statement to keep the text of the query, so the engine can re-prepare
the satement and try to step again, transparently to the caller.
4. Once the first sqlite3_step succeeds, an implicit transaction is
started (I assume there are no explicit transactions in effect), so the
schema can no longer change unexpectedly.
Igor Tandetnik
