[QGIS-Developer] GPKG and FID -- can we fix this mess?

[Even Rouault]

> 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