[QGIS-Developer] Geopackage FID columns: i HATE them!!!!

[René-Luc Dhont]

I agree, so in my algorithms working with geopackage I always redefined  
FID with

options = QgsVectorFileWriter.SaveVectorOptions()
options.layerOptions = ['FID=id']

For me it is like a primary key in PostGIS, I need to manage it.
Other point, Feature ID in QGIS is still a short integer.

Regards,
René-Luc

Le 19/03/2020 à 10:28, Régis Haubourg a écrit :
> +1000. I was so relieved of the fid/oid/mapinfo_id when QGIS arrived 
> and allowed business logic primary keys.
>
>
> Le jeu. 19 mars 2020 à 07:52, Nathan Woodrow <madmanwoo at gmail.com 
> <mailto:madmanwoo at gmail.com>> a écrit :
>
>     I agree.
>
>     If there is an ID that is used internally as a unique primary key
>     it should never be shown to the user. It should not be expected to
>     be edited outside of the provider's control or be stable between
>     edits.
>
>     If you need a stable ID for reference you should make your own
>     {{insert rant about people wanting to use increating ints as a
>     reference ID}}
>
>     On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson
>     <nyall.dawson at gmail.com <mailto:nyall.dawson at gmail.com>> wrote:
>
>         Hi list,
>
>         Just wondering what everyone's thoughts are about geopackage FID
>         columns. Personally, I find them an absolute nightmare to deal
>         with,
>         resulting in annoying (and dangerous) issues when trying to save
>         geopackage edits, such as
>         - field type issues: converting certain formats to geopackage
>         fails,
>         because existing fields with name "fid" are of an incompatible
>         type
>         with geopackage. Solution: manually uncheck the "fid" field
>         from the
>         "save as" dialog.
>         - unique constraint violations: we've mostly fixed this in
>         processing,
>         but it's still unfortunately really common to get failures
>         when saving
>         edits to geopackage because some operation has resulted in
>         duplicate
>         fids. This can be a nightmare to fix, if it's even possible to
>         do so.
>
>         I personally HATE HATE HATE these columns, and would rather I
>         never
>         saw them ever again. Does anyone else feel the same? If so,
>         could we
>         potentially just permanently hide these columns from QGIS and
>         avoid
>         all these dangerous issues for users?
>
>         Nyall
>         _______________________________________________
>         QGIS-Developer mailing list
>         QGIS-Developer at lists.osgeo.org
>         <mailto:QGIS-Developer at lists.osgeo.org>
>         List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>         Unsubscribe:
>         https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200319/8684d3dc/attachment.html>