Nyall Dawson <nyall.daw...@gmail.com> writes: > On Wed, 12 Jan 2022 at 11:00, Greg Troxel <g...@lexort.com> wrote: >> >> >> <perg...@gmail.com> writes: >> >> > A. Ideally WAL/DELETE would be a connection (in the sense of the >> > Browser connections list) level decision changeable by the user, not a >> > layer-level decision and not (as now) an application setting used for >> > all gpkg connections. >> >> Fundamentally WAL/DELETE is a (changeable) property of an sqlite3 file, >> and thus of a geopackage container. So exposing it as a db browser >> property and allowing it to be changed, with a warning that it is a DB >> Admin operation, not a connection operation, seems ok. > > Instead of exposing this as a per-workstation, QGIS only property, I'd > propose instead that the property be set somewhere in the gpkg > metadata itself, so that regardless of which user opens it in a > multi-user environment, they'll always get the property set by the db > administrator. (Maybe this could even become a future formal gpkg > extension...?)
Right now, I think WAL/DELETE is a property of the sqlite3 file which contains the geopackage data. But it's a sqlite3 property, not a geopackage property. (And qgis whacks it on every open.) If I am following, you are suggesting a geopackage-level property (in some table?), and a rule that when a reader or write opens the file, if the sqlite3 setting does not match, the sqlite3 setting is forced and an error is logged? If I got that wrong which I probably did, I wonder what you do mean.
signature.asc
Description: PGP signature
_______________________________________________ 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
