<div dir="ltr"><div dir="ltr">On Fri, Mar 20, 2020 at 6:04 PM matteo <<a href="mailto:matteo.ghetta@gmail.com">matteo.ghetta@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
+1000 from an user perspective the fid is really confusing. The user<br>
seems to be able to delete/edit the column but (of course) touching it<br>
will throw an error when saving.<br>
<br>
Moreover, it happens that during format conversion in the attribute<br>
table there are fid/pk/id columns, with same numbers.<br><br></blockquote><div><br></div><div>I can imagine it is frustrating for users. It would be better not to have the system fid at all.<br><br>We originally asked for this feature to be implemented in QGIS a few years back - so we are to blame! Our issue was GeoPackage files were being created from a data service with the source data primary key set as the FID, and we couldn’t see this PK data in QGIS. This situation has now changed, and the fid and source primary keys are both in the GPKG now. However, the other issue with removing the fid column, is we have python scripts using GDAL, creating GeoPackages with the layer creation options of FID=id. This was so we can easily apply change-sets the database using the GDAL Python API of `layer.GetFeature(fid)` rather than having to use `layer.SetAttributeFilter(‘ID=XXX’)` (which also requires the creation of a user index to be efficient). We also support PostGIS, MSSQL, and FileGDB data sources in this same way. Happy if people have some thoughts on better ways to do this :-) Maybe we can change QGIS only to display the GPKG FID if it is not set to ‘fid”? I guess there might be other issues with that approach in terms of editing...<br></div><div><br></div><div>Cheers</div><div>Jeremy</div><div><br></div></div></div>