API call instead of PRAGMA schema_version?
(1) By Paul van Helden (paulvh) on 2020-10-07 09:15:32 [link] [source]
I can't find such, please let me know if there is one.
(I know I can get it by reading the header at offset 40, which I'd rather not do).
My reasoning is to be able to quickly check for a schema change to invalidate cached information about tables. There would probably be little difference in speed (compared to doing a PRAGMA) but we have sqlite3_table_column_metadata(), why not a sqlite3_schema_version() ?
(2) By Paul van Helden (paulvh) on 2020-10-07 09:17:12 in reply to 1 [link] [source]
A schema change hook would also be great...
(3) By Richard Hipp (drh) on 2020-10-07 10:53:22 in reply to 1 [link] [source]
If you open the database file and read bytes 40 through 43 directly, the following things can go wrong:
You won't see changes that have been committed to the Write-Ahead Log (WAL) file but not yet checkpointed.
You might not see uncommitted changes that are in the process of being made by your application.
You might get an inconsistent answer if another process is changing the value at the same time you are reading it.
If you do this on unix (linux, mac, raspberry-pi) then all database locks will be cancelled when you close the file descriptor that you used to read the database header (due to a design bug in posix advisory locks, that SQLite has to go to a lot of trouble to work around) which can lead to subsequent database corruption.
(4) By Paul van Helden (paulvh) on 2020-10-08 13:04:00 in reply to 3 [link] [source]
...which is why I wrote I'd rather not do that.
(5) By anonymous on 2020-10-09 02:50:58 in reply to 3 [source]
Actually, there is
SQLITE_FCNTL_FILE_POINTER, so you need not open the file yourself; that deals with item 4 in that list (since you need not deal with the file descriptor yourself). Still, it is complicated and less efficient to have to deal with all of these things, rather than just using