Bug report #18007
QGIS 3 Vector data corruption when Adding a Point Feature
|Affected QGIS version:
|Pull Request or Patch supplied:
|Crashes QGIS or corrupts data:
|Copied to github as #:
Attached is a sample data set to illustrate the problem. This was broken off as a separate issue from #17878.
To create the issue load test.gpkg into QGIS. Open the Attribute Table. The attribute table should look something like 'attribute_table_before.jpg'. Now click on the "Toggle Editing" toolbar icon and then click on the "Add Point Feature" icon. Now click anywhere on the map canvas to add a feature. For 'label' I called it test and left 'latitude' and 'longitude' as NULL. The net results is that this new data is added to line 6 with 'Autogenerate' as the fid (which is probably now what it should do), but the big problem is that Row 1 data becomes corrupted in the fields 'latitude' and 'longitude'. It looks like these fields were truncated to two decimal places. Adding a new feature should not affect row 1 at all. See 'bad_data.jpg' for what happens.
[bugfix] Lower priority of range widget for doubles
This was the root cause of several critical bugs with
data corruption in the attribute table and forms:
SpinBox has a fixed number of decimal places, which
makes it not ideal for floating points because most
of the times it rounds the number changing it when
in edit mode even if the user has not really modified
the value by writing in the spin box or using the
So, the defult is now back to the line edit (which has
bugs in the validator, but that's another less
critical and separate issue).
#2 Updated by Alessandro Pasotti about 6 years ago
- Pull Request or Patch supplied changed from No to Yes
- Assignee set to Alessandro Pasotti
- Status changed from Open to In Progress
Thanks for filing this, the root of this issue and of others related issues as well is that the default widget for "double" is now the spinbox widget, that has a fixed number of decimal places .
After my recent commits, the number of decimal places can be set by the user in the widget field options, but by default it takes the precision as reported by the provider, which is most of the times 0 (pure nonsense for a double).
But, even if the precision can now be set to something higher than 2 (the old default), you'll always (well, almost) have rounding errors that will alter the original value even if you don't directly edit it.
So, IMHO the only way out is to go back to the plain old lineedit widget by default (like it was in 2.x). See my comments in https://github.com/qgis/QGIS/pull/6209 and the new PR:
There is still a bug in the validator (which is basically not used) but I'll file a separate ticket (or - faster - just fix it)