Bug report #12139
record saved reversed in spatialite layer
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: | - | ||
| Category: | Data Provider/SpatiaLite | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 20333 |
Description
when new objects are inserted into a spatialite layer, records are inserted reversed.
This is no a real bug but it can create some problem and confusion. In my case I copied records from one layer to another and my primary keys were been inverted, so I lost all the connection with related table. I also notice that this behavior create confusion in many users.
It seems that the problem start from Qgis 2.2 but this need to be confirmed.
Associated revisions
Fix #12139 - added features saved in reversed order
History
#1
Updated by Giovanni Manghi about 9 years ago
- Status changed from Open to Feedback
Hi, could you make an example? I just tested here on qgis master and I can't see any issue (but maybe I have not understand the problem). Cheers.
#2
Updated by Luca Lanteri about 9 years ago
As I said it's not a real issue but just an odd behaviour that can be boring or can create confusion.
With the attached test.sqlite: add 3 point with name A,B and C and then save. I expect those gid-name pairs: 1-A, 2-B, 3-C but I have got those: 1-C,2-B,3-A.
And there is another "strange case" (but it can be a separate case):
- Insert a fourth point with name = "D"
- delete point with gid =3.
- copy all points from layer test to layer test2.
QGIS doesn't copy the gid column but assign a new sequence value, so I have those pairs: 1-A, 2-B, 3-C
In my database gid is the primary key and some others table reference it.
The result is that I can't copy objects from one table to another because I lost my primary key.
Instead, If I perform this operation with an sql operation I obtain those (correct) pair: 1-A, 2-B, 4C
I think it's better to have coherent behavior in table and sql c&p operations.
#3
Updated by Giovanni Manghi about 9 years ago
With the attached test.sqlite:
I think you missed the attachment. Cheers!
#5
Updated by Giovanni Manghi about 9 years ago
mescal72 - wrote:
As I said it's not a real issue but just an odd behaviour that can be boring or can create confusion.
With the attached test.sqlite: add 3 point with name A,B and C and then save. I expect those gid-name pairs: 1-A, 2-B, 3-C but I have got those: 1-C,2-B,3-A.
now I see, really not handy. Could you say if it is a regression?
#6
Updated by Giovanni Manghi about 9 years ago
- Affected QGIS version changed from 2.6.0 to master
#7
Updated by Luca Lanteri about 9 years ago
Surely it is a regression from version 2.0, but I'm not sure if the 2.2 is the first version affected.
#8
Updated by Giovanni Manghi about 9 years ago
- Priority changed from Normal to Severe/Regression
#9
Updated by Jürgen Fischer about 9 years ago
That the primary key columns are skipped and replaced with the defaults is a feature - otherwise there might be conflicts when you copy features and splitting doesn't work (because the splitted features get the same set of attributes as the original feature). See also #7550.
#10
Updated by Martin Dobias about 9 years ago
- Status changed from Feedback to Closed
Fixed in changeset d8083b96ef3eb8761684036e794b97981124c51f.