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

[Even Rouault]

On jeudi 15 octobre 2020 17:48:30 CEST Matthias Kuhn wrote:
> If there is a managed database where there has been a conscious decision to
> have an integer id column (postgres case) and workflows are built around
> this: filling the id on insert, building foreign keys against it etc, that
> works just fine.
> 
> But if GeoPackage is used as a generic dataformat (typical Shapefile
> replacement), requirements are different and workflows less managed. E.g.
> The "simple" case of merging two datasets already poses the question what
> to do with the two colliding fid attributes. Delete the original fid
> columns and regenerate one. Or preserve both and generate a new one
> (leading to fid, fid_1 and fid_2).
> 
> If we look at the fid attribute as part of the data (where we have foreign
> keys pointing two etc) we want it to be preserved.
> If we look at it as a purely internal technical id (for RTree management
> etc) we don't care for it and can just regenerate and forget about it.
> 
> It looks as if we need to keep it as a technical id.
> I like the idea to transparently generate it in addFeature.
> I would also prefer to hide it away from the user and only leave it
> available through $id. This would make it clear to users that it's for
> internal use and no one would expect it to be preserved after a merge
> operation. For backwards compatibility there could be a provider flag to
> re-enable it.
> I hope that makes sense.

As I like playing devil's advocate :-), one issue I can think of is : how can 
you know when you open a GeoPackage, possibly created by another software, if 
the integer primary key column is a technical one (that could perhaps be 
hidden), or a "real" one part of the data and intended to be user visible ? So 
we would need some user feedback... Or maybe more simply, for pure QGIS 
workflows, we could decide for a new value for the fid column name when we 
create a GPKG table, like "hidden_fid", and when opening such GeoPackage, 
decide to not expose it as a field. That could solve issues for GPKG created 
from now by QGIS, while still providing some backward compatibility. And 
people wanting to still have a visible fid, and ready to deal with possible 
annoyances, could overload this "hidden_fid" value with another value.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com