Bug report #16935
Editing a Spatiallite/GPKG layer added by d&d (or DB Manager) leads to error and data corruption
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||Yes||Resolution:||fixed/implemented|
|Crashes QGIS or corrupts data:||Yes||Copied to github as #:||24834|
1) create a new spatialite db and a layer in it (layer > create layer > new spatialite layer), for example a polygon one in WGS84 CRS
2) digitize a polygon and save
3) start a new project
4) add the above layer in the new project by dragging and dropping the Spatialite DB from outside QGIS within the QGIS main window
5) put the layer in edit mode, split the polygon with the "split features" tool, try to save
Could not commit changes to layer teste aaa Polygon
Errors: SUCCESS: 1 geometries were changed.
ERROR: 1 feature(s) not added.
OGR error creating feature -2: sqlite3_step() failed:
UNIQUE constraint failed: aaa.pkuid (19)
6) discard changes > one of the polygons result of the split will vanishes
7) try all the about from the "add spatialite layer" dialog, the problem will not occur
#1 Updated by Giovanni Manghi over 3 years ago
- Category changed from Data Provider/SpatiaLite to Vectors
- Subject changed from Editing a Spatiallite layer added by d&d leads to error and data corruption to Editing a Spatiallite/GPKG layer added by d&d leads to error and data corruption
Correction, this is not specific of Spatialite, it happens the same with GPKGs
#2 Updated by Giovanni Manghi over 3 years ago
- Subject changed from Editing a Spatiallite/GPKG layer added by d&d leads to error and data corruption to Editing a Spatiallite/GPKG layer added by d&d (or DB Manager) leads to error and data corruption
It affects also GPKGs added via DB Manager, while Spatialite layers seem ok (from DB Manager).
#4 Updated by Alessandro Pasotti over 3 years ago
- Status changed from Open to Feedback
- Affected QGIS version changed from 2.18.11 to master
What's happening here is pretty clear: by splitting the polygon you create a new geometry, but the primary key of the table is just copied from the original feature attribute, when you commit the DB refuses to save due to a UNIQUE constraint in the primary key.
I think this is the expected behavior: what do you think should happen? (what is the expected behavior for the the primary key value?)
#5 Updated by Alessandro Pasotti over 3 years ago
Ok, got the error but I'm still unsure about the solution: what happen here is:
- the split geometry operation is done within 2 distinct operations:
- 1) change the original geometry
- 2) insert the new splitted geometry
- the order is clearly wrong, because if the insert fails (which it does) you end up with the original geometry splitted but without the new splitted part
- even if you change the order and commit changes, it will fail because (and here comes the real ugly issue) the order of various operations in the commitChanges is completely ignored (the order is always the same: first change all the geometries then insert all the features)
#6 Updated by Alessandro Pasotti over 3 years ago
#10 Updated by Alessandro Pasotti over 3 years ago
@giovanni, not sure: probably slightly related, if you want I can have a look to see if I can fix it in the same way I fixed this one.
Btw, there is a more general problem about rollbacks on complex editing operations, by wrapping the editing commands in transactions for the data sources that supports them. Maybe worthwhile to file a separate ticket for that.