On Thu, Oct 15, 2020 at 7:23 PM Even Rouault <[email protected]> wrote:
> 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... Correct, QGIS can't know. I as a user have better chances. I was trying to propose to pass this as a parameter to the data provider (as an option in the add layer dialog). This is not necessarily easy to implement. 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. > This sounds like a simple while powerful solution. Matthias > 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
