> The way I see it, fid can be seen very similarly to rowid or shapefile > fids. A semi-stable unique identifier. Just - and that's the big difference > - those are not part of the data hence the system can transparently deal > with duplicates and can fill holes once in a while (shp -> repack, sqlite > rowid -> vacuum).
Well, no, a fid is by definition a identifier. Something that must be stable ideally. In the shp or sqlite with rowid, this is not a genuine fid. If you claim to have a fid, this is something you could use to do joins or create foreign keys upon. It shouldn't change after database recompaction. > > If I could choose I would just make fids disappear (not only from the > interface but from all the gpkg implementation). Really, it looks to me "only" to be an implementation issue on our side. The concept of having a fid column is not something horrific per se. Many other databases have one ! > So just to have brought up the idea: Could we make fids optional for newly > created gpkgs. Or is my fear that this will affect interoperability in a > bad way correct? You would create non-standard compliant GeoPackage. They would fail the OGC compliance testing and probably might be rejected by other implementations, which would defeat the purpose of being an exchange format. Hum actually digging further, you would break even QGIS itself when using a spatial index. The triggers that update the RTree need a fid column. So if you used rowid instead and do a VACCUUM, you would break the spatial index (the RTree nodes would refer to other rows than the ones it has been built upon...). Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer