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 _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
