Bug report #12139

record saved reversed in spatialite layer

Added by Luca Lanteri almost 6 years ago. Updated almost 6 years ago.

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.

test.sqlite (134 KB) Luca Lanteri, 2015-02-09 07:03 AM

Associated revisions

Revision d8083b96
Added by Martin Dobias almost 6 years ago

Fix #12139 - added features saved in reversed order

History

#1 Updated by Giovanni Manghi almost 6 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 almost 6 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 almost 6 years ago

With the attached test.sqlite:

I think you missed the attachment. Cheers!

#4 Updated by Luca Lanteri almost 6 years ago

here the attachment, sorry....

#5 Updated by Giovanni Manghi almost 6 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 almost 6 years ago

  • Affected QGIS version changed from 2.6.0 to master

#7 Updated by Luca Lanteri almost 6 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 almost 6 years ago

  • Priority changed from Normal to Severe/Regression

#9 Updated by Jürgen Fischer almost 6 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 almost 6 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF