[Qgis-user] Readonly gpkg

[Even Rouault]

Le 11/01/2022 à 18:58, Greg Troxel a écrit :
> Jürgen E. Fischer <jef at norbit.de> writes:
>
>> On Tue, 11. Jan 2022 at 09:10:57 -0500, pergler at gmail.com wrote:
>>> I've tried making the gpkg read-only, which hasn't crashed anything in brief
>>> testing and generates no warnings. However, it feels risky, and clearly QGIS
>>> or OGR aren't fully happy, since the temporary shm and wal files don't get
>>> deleted on exit. So I'm hesitant to continue doing this for fear of a crash
>>> when I'm actually doing something useful.
>> We do the same with world_map.gpkg - see
>> https://github.com/qgis/QGIS/issues/35383.
> I had seen that (NetBSD 9, pkgsrc, qgis 3.16.x) and wondered if it was a
> packaging error I should look into.  Now I understand.   I have long
> found it problematic that the wal/shm files exist and persist for long
> periods, and that gpkd files I don't intend to change are modified at
> the OS level.
>
> It strikes me that the basic bug needs one of two things:
>
>    1) The geopackage driver should have a read-only access mode, and qgis
>    should start out that way, trying to change to read/write only when
>    the user hits the edit button on one of the layers.  And, if the file
>    is read only, there should be a nice error like "can't make this layer
>    writable" and the toggle to write should fail.

The main issue I see is that it is unknown (and non documented AFAICS in 
SQLite documentation) what happens if :

- reader A has opened the file with default journaling mode (for read-only)

- reader B (other QGIS process for example, or possibly the same QGIS 
process like a renderer thread) has opened the file with default 
journaling mode (for read-only)

- let's say A wants to edit and we thus enable WAL to avoid 
reader/writer blocks

- is B which has opened without WAL still in a safe state ? Does it 
react properly to WAL having been enabled behind its back ?

The default enabling of WAL even in initial read-only access mode is to 
avoid that potential issue.


There are currently way of disabling WAL (for advanced users) :

- setting the OGR_SQLITE_JOURNALenvironment variable to JOURNAL

- or setting the QGIS setting "qgis/walForSqlite" to false

See 
https://github.com/qgis/QGIS/blob/master/src/core/providers/ogr/qgsogrproviderutils.cpp#L1005

>
>    With this option, there perhaps needs to be some kind of lock outside
>    of sqlite, which can be multireader and single writer.
>
>    2) somehow, the geopackage layer could hide all this and logically open
>    the layer read/write, but refrain from writing to the filesystem.
>    Then, when there is an actual write, the db open-for-write can
>    happen.   After the database is written, if no layers [are
>    editable]or[have unwrittend changes] for some period of time (5m?) the
>    database should be changed back to read only.   This is sort of like 1
>    but at the gdal layer vs the qgis layer.
>
>
> Because of this I'm starting to think about moving all my data into
> postgis, and not use geopackages any more.
>
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20220111/225c47da/attachment-0001.html>