Bug report #11498
spatialite layer added via browser lose first field
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Data Provider/OGR | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 19768 |
Description
When loading a spatialite layer using browser (browsing the file, not using the connection) the first field of the table (may be only if it's a pkey) is not shown
Related issues
History
#1
Updated by Giovanni Manghi almost 10 years ago
- Status changed from Open to Feedback
cannot replicate in qgis master, can you attach sample data?
#2
Updated by Luca Lanteri almost 10 years ago
You have to add the SL layer using the browser view, not the SL connection. Just tested now on 2.4.
#3
Updated by Giovanni Manghi almost 10 years ago
mescal72 - wrote:
You have to add the SL layer using the browser view
I did
#4
Updated by Salvatore Larosa almost 10 years ago
I cannot replicate neither on 2.4 nor on master.
Tested with a table with primary key and polygon geometry.
a small sample data to replicate the issue is necessary.
#5
Updated by Luca Lanteri almost 10 years ago
- File test.sqlite added
You're right: I try with a brand new DB and it works, but if I use some other DB the problem persists.
I can't understand if it's a SL version problem. All my databases may be: SpatiaLite version 4.1.1
and SQLite version 3.8.2. I'll try to investigate deeper.
I try to attach an example db.
#6
Updated by Salvatore Larosa almost 10 years ago
neither with the attached DB, I see with both browser and add button:gid,arpa,id,_old,attivita
I am trying with SL 4.0.0 and SQLite 3.7.13
#7
Updated by Luca Lanteri almost 10 years ago
mmm...
I also view all field if I load it via SL connection (using the "feather" button or browser with SL connection), but If I browse the file system using browser I lose the "gid" field.
I tested it on linux and win7 and QGIS 2.0 and 2.4.
I really not understand how to replicate it but I'm sure it isn't a local problem
#8
Updated by Giovanni Manghi almost 10 years ago
- Status changed from Feedback to Open
- Affected QGIS version changed from 2.4.0 to master
Salvatore Larosa wrote:
neither with the attached DB, I see with both browser and add button:
gid,arpa,id,_old,attivita
I am trying with SL 4.0.0 and SQLite 3.7.13
ok now I see: in the browser one must add the SL layer by browsing directly the SL file, not the connection.
#9
Updated by Salvatore Larosa almost 10 years ago
- Category changed from Browser to Data Provider/OGR
- Status changed from Open to Feedback
I see now, but it is an OGR provider issue and occurs only when a primary key was defined.
The FID Column
has not fetched by ogr provider, but that might be considered as an expected behavior(?)
#10
Updated by Luca Lanteri almost 10 years ago
From the user point of view I think it can't be considered as an expected behavior primary because it's different from the "connection behaviour" and may generate confusion.
#11
Updated by Salvatore Larosa almost 10 years ago
Yeah, I am in favour to the current behavior like the OGR provider does, I would like to extend it to the SL provider too.
Thoughts??
#12
Updated by Luca Lanteri almost 10 years ago
I think this isn't the right choice.
For a lot of reason I prefer to have the FID visible as occour for all other data source (e.g. for postgis layer).
#13
Updated by Jukka Rahkonen almost 10 years ago
If FIDs are visible can you still prevent users from editing them and making a disaster?
#14
Updated by Luca Lanteri almost 10 years ago
If you need you can de-check the editable option from the "Edit widget option". I thinks it's preferable to leave this choice to users. Moreover without a visible FID it's not possible to uniquely identify features.
#15
Updated by Jukka Rahkonen almost 10 years ago
I must admit that I do not really use QGIS much. In WFS it is normal to hide FIDs from the users and it looks like QGIS WFS client is hiding them also. For my mind FIDs are for the system but I understand that sometimes it it good to be able to see them. However, editing FIDs is usually an extremely bad idea. For example if Spatialite happens to accept such edit it will invalidate spatial index and ruin foreign key relations. But perhaps I do not need to worry and QGIS and database drivers + triggers in the databases can prevent all the damage.
#16
Updated by Luca Lanteri over 9 years ago
A solution can be to set the FID field uneditable by default into the edit widget option and prompt users with a warning if they select the editable option.
#17
Updated by Giovanni Manghi over 8 years ago
- Status changed from Feedback to Open
#18
Updated by Giovanni Manghi over 8 years ago
see also #6226
#19
Updated by Even Rouault almost 8 years ago
- Target version set to Version 2.16
- Status changed from Open to Closed
- Resolution set to fixed/implemented
This issue was solved in QGIS 2.16.0 for a set of OGR drivers like spatialite, GPKG, etc...