On 03/29/2017 02:48 AM, Bob Friesenhahn wrote:
We are trying to update from sqlite3 3.10 to 3.17. Our virtual table
modules are encountering problems with 3.17 since the 'xOpen' callback
is now being called for value change and row deletion operations.
Previously it was only being called for read-only queries.
Something else is going on I think. There has never been a version of
SQLite that could do an UPDATE or DELETE on a virtual table without
invoking xOpen() to create a cursor. It needs the cursor to determine
which rows are matched by the WHERE clause.
We are using reader/writer locks and there is not a convenient way to
transition from being a reader to being a writer. A file is opened by
the 'xOpen' callback and we need to know if the file should be opened
read only, or read/write.
The change in behavior can only work with virtual table modules which
are able to smoothly transition between the state established by
'xOpen' to the 'xUpdate' call or know the intent when 'xOpen' is
called. This did not seem to be a requirement before.
In what sqlite3 version did this behavior change?
Is there a way to know when the 'xOpen' callback is called if it is to
support an update transaction (i.e. 'xUpdate' callback will be called)?
When a write-transaction is opened on a virtual table the xBegin method
is called. xCommit() or xRollback() to end the transaction. Any xOpen()
that is part of an UPDATE or DELETE operation will occur within a
transaction, and any xOpen() outside of a transaction must be a
read-only query. But within an open transaction there is no way to tell
whether a specific xOpen() call is part of a read-only or read-write
statement.
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
