Bug report #15351

geopackage edits workflow is broken

Added by Giovanni Manghi over 7 years ago. Updated almost 7 years ago.

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

Revision b6b8759e
Added by Even Rouault over 7 years ago

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

Revision 0497e4a4
Added by Even Rouault over 7 years ago

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

Revision 58547c7e
Added by Even Rouault over 7 years ago

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

Revision f939e9cf
Added by Even Rouault over 7 years ago

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 7 years ago

  • Category changed from Vectors to Data Provider/OGR

#2 Updated by Giovanni Manghi over 7 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 7 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 over 7 years ago

  • Assignee set to Even Rouault

#5 Updated by Even Rouault over 7 years ago

  • Status changed from Reopened to Closed

#6 Updated by Even Rouault over 7 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 almost 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 almost 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 almost 7 years ago

  • Status changed from Feedback to Closed
  • Resolution set to worksforme

Closing for lack of feedback, please reopen if necessary.

Also available in: Atom PDF