Detect whether database was opened in shared cache mode
(1) By Aloys (aloys) on 2020-04-30 21:27:32 [link] [source]
From the documentation I see that function sqlite3_enable_shared_cache allows to globally enable or disable shared cache mode, and that a user can select shared cache mode on opening a database file either by setting an open flag or the URI parameter cache - overriding the global setting.
However, I didn't find a function to query the state of shared cache mode, neither the global setting nor whether a database was opened in shared cache mode or not.
Did I overlook anything? Is there a method to find out whether a database file was opened in shared cache mode or not?
Thanks in advance for any hints.
(2) By Richard Hipp (drh) on 2020-05-01 12:00:11 in reply to 1 [link] [source]
No, there is no interface to determine after-the-fact whether or not a database was opened in shared cache mode.
(3) By Aloys (aloys) on 2020-05-01 13:28:54 in reply to 2 [link] [source]
Is this on purpose that such an interface is missing? For almost all options and features there are functions or pragma statements to query the current status. Why not for the shared cache mode?
I guess that internally SQLite must be able to determine this to take the right actions. Maybe function sqlite3_db_status could be extended to return this information?
(4) By Richard Hipp (drh) on 2020-05-01 13:51:34 in reply to 3 [source]
The shared-cache feature was invented many years ago, for use on SymbianOS phones. It was a clever work-around to provide for the concurrency needs of SymbianOS, at that time. But these days, WAL-mode is much preferred, and shared-cache is considered a mistake and a misfeature. Shared-cache continues to be supported because it is a legacy interface that we have promised to maintain backwards compatibility. But we don't like it, and don't want to encourage people to use shared-cache by provisioning it with new capabilities.
(5) By Aloys (aloys) on 2020-05-01 14:07:39 in reply to 4 [link] [source]
Ok, I understand. Thank you very much for the explanation.
However, if you want to discourage the use of shared cache, you could maybe change the build logic for future SQLite versions. That is, instead of having the option SQLITE_OMIT_SHARED_CACHE the option SQLITE_ENABLE_SHARED_CACHE could be introduced.
(6) By Richard Hipp (drh) on 2020-05-01 14:20:11 in reply to 5 [link] [source]
That's a good suggestion. I just checked, and omitting shared-cache makes the SQLite both smaller (by about 1%) and faster (by about 0.3%). I will consider changing shared-cache to an opt-in rather than opt-out beginning with 3.33.0.