I think the simplest and safest change is to remove all code that
changes the journal mode as a side effect of access. People that want
WAL can pragma it on, with DBA hat on. In my view sqlite's WAL option
breaks the previous concept that you can have a database without
understanding databases, and as long as it's a DBA choice, that's ok.
WAL is really a programmer level concept. I'm not sure a QGIS advanced
user/admin should be aware of that.
Separately from the "DBA chooses journal mode" view, I feel that
constantly flipping the journal mode is asking for trouble. I suppose
one could write a test with N processes that each connect, set a random
choice of WAL or DELETE, wait a bit, do a transaction to increment a
value, perhaps repeat that, and then if they set WAL set DELETE and
exit, as a way to look for races. Maybe sqlite3's own tests already do
that.
If you do no turn WAL on when editing, the following QGIS tests will
fail (and some real world situations like where you have a huge layer
being refreshed in the background while trying to edit it):
https://github.com/qgis/QGIS/commit/b6b8759efbeb833d0d3dbf6df008087701361ad3#diff-56354e2446fe2cb6d1ee92d4e984091172e964e90f3be4d3d42276e033c4986eR92
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
