Bug report #15351
geopackage edits workflow is broken
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: |  Even Rouault | ||
| Category: | Data Provider/OGR | ||
| Affected QGIS version: | 2.14.3 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | worksforme |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 23283 |
Description
Make same edits to a geopackage layer, just geometry edits or just attributes ones, all works ok.
Now do the following:
- toggle editing
- do a geometry edit (do not yet save edits)
- make any operation involving attributes, like identify, open attribute table, etc.
- try save edits: "Layer comu3: OGR error setting feature 277: failed to execute update : database is locked"
this is replicable 100% of the times.
Not sure of how to prioritize the issue... seems pretty bad.
As seen on QGIS master and 2.16 and 2.14.
Associated revisions
Fix database locking when editing GeoPackage
Concurrent read and write can lock a GeoPackage database given
the default journaling mode of SQLite (delete). Use WAL when
possible to avoid that.
Fixes #15351
Fix database locking when editing GeoPackage
Concurrent read and write can lock a GeoPackage database given
the default journaling mode of SQLite (delete). Use WAL when
possible to avoid that.
Fixes #15351
Fix database locking when editing GeoPackage
Concurrent read and write can lock a GeoPackage database given
the default journaling mode of SQLite (delete). Use WAL when
possible to avoid that.
Fixes #15351
Fix database locking when editing GeoPackage
Concurrent read and write can lock a GeoPackage database given
the default journaling mode of SQLite (delete). Use WAL when
possible to avoid that.
Fixes #15351
History
#1
Updated by Alessandro Pasotti over 8 years ago
- Category changed from Vectors to Data Provider/OGR
#2
Updated by Giovanni Manghi over 8 years ago
- Status changed from Open to Closed
- Resolution set to not reproducable
sorry for the noise but despite my efforts I'm unable to replicate today what yesterday I was getting all the time.
#3
Updated by Giovanni Manghi over 8 years ago
- Resolution deleted (
not reproducable) - Affected QGIS version changed from master to 2.14.3
- Status changed from Closed to Reopened
- Priority changed from Normal to Severe/Regression
The issue is definitely there, is/was kind of puzzling to find a pattern.
So, what I'm seeing at the moment (hopefully this is really a pattern) is:
2.6.1 (gdal 1.11) ok
2.8.8 (gdal 2.0.2) ok
2.10.1 (gdal 1.11.2) not ok
2.12.0 (gdal 1.11.3) not ok
2.14.3 (gdal 2.1.0) not ok
2.16.0 (gdal 2.1.0) ok on Windows
2.16.0 (gdal 2.1.0) not ok on Linux
what "not ok" means:
steps to replicate are similar to the ones in the original description
- toggle editing
- do a geometry edit (do not yet save edits)
- open attribute table
- try save edits > error like "Layer comu3: OGR error setting feature 319: failed to execute update : database is locked"
Here the tricky part.
On 2.14.3:
- if the edit was adding a new feature then when saving (do not forget to open the attribute table before, otherwise no problems) first is shown a warning like "Commit errors: Could not commit changes to layer comu3", but if the user try saves again (ignoring the warning and the subsequent error) then the feature is correctly saved
- if the edit was moving a node or moving a feature then there is no warning and an error is directly thrown ("Layer comu3: OGR error setting feature 319: failed to execute update : database is locked") and the edit reverted.
On 2.10 and 2.12 the observations are similar to 2.1.4.3
On the other hand it seems that on 2.16.0 on Windows is all ok, but... on Linux with the same QGIS version compiled against the same GDAL version the behavior is ok regarding new features, but regarding moving nodes or moving features the problem is the same as in 2.14.3.
I'm tagging this as a regression because the actual LTR is affected and the old LTR wasn't.
#4
Updated by Even Rouault about 8 years ago
- Assignee set to Even Rouault
#5
Updated by Even Rouault about 8 years ago
- Status changed from Reopened to Closed
Fixed in changeset b6b8759efbeb833d0d3dbf6df008087701361ad3.
#6
Updated by Even Rouault about 8 years ago
- Target version set to Version 2.14
- % Done changed from 0 to 100
- Resolution set to fixed/implemented
#7
Updated by Ger CO over 7 years ago
- Status changed from Closed to Reopened
Unfortunately, after the first successful edit, I get the "database is locked" error using qgis 2.18.5 on windows
#8
Updated by Giovanni Manghi over 7 years ago
- Resolution deleted (
fixed/implemented) - Status changed from Reopened to Feedback
Ger CO wrote:
Unfortunately, after the first successful edit, I get the "database is locked" error using qgis 2.18.5 on windows
can you post sample data, and exact steps to replicate? thanks.
#9
Updated by Giovanni Manghi over 7 years ago
- Status changed from Feedback to Closed
- Resolution set to worksforme
Closing for lack of feedback, please reopen if necessary.