<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 7:23 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On jeudi 15 octobre 2020 17:48:30 CEST Matthias Kuhn wrote:<br>
> If there is a managed database where there has been a conscious decision to<br>
> have an integer id column (postgres case) and workflows are built around<br>
> this: filling the id on insert, building foreign keys against it etc, that<br>
> works just fine.<br>
> <br>
> But if GeoPackage is used as a generic dataformat (typical Shapefile<br>
> replacement), requirements are different and workflows less managed. E.g.<br>
> The "simple" case of merging two datasets already poses the question what<br>
> to do with the two colliding fid attributes. Delete the original fid<br>
> columns and regenerate one. Or preserve both and generate a new one<br>
> (leading to fid, fid_1 and fid_2).<br>
> <br>
> If we look at the fid attribute as part of the data (where we have foreign<br>
> keys pointing two etc) we want it to be preserved.<br>
> If we look at it as a purely internal technical id (for RTree management<br>
> etc) we don't care for it and can just regenerate and forget about it.<br>
> <br>
> It looks as if we need to keep it as a technical id.<br>
> I like the idea to transparently generate it in addFeature.<br>
> I would also prefer to hide it away from the user and only leave it<br>
> available through $id. This would make it clear to users that it's for<br>
> internal use and no one would expect it to be preserved after a merge<br>
> operation. For backwards compatibility there could be a provider flag to<br>
> re-enable it.<br>
> I hope that makes sense.<br>
<br>
As I like playing devil's advocate :-), one issue I can think of is : how can <br>
you know when you open a GeoPackage, possibly created by another software, if <br>
the integer primary key column is a technical one (that could perhaps be <br>
hidden), or a "real" one part of the data and intended to be user visible ? So <br>
we would need some user feedback... </blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Or maybe more simply, for pure QGIS <br>
workflows, we could decide for a new value for the fid column name when we <br>
create a GPKG table, like "hidden_fid", and when opening such GeoPackage, <br>
decide to not expose it as a field. That could solve issues for GPKG created <br>
from now by QGIS, while still providing some backward compatibility. And <br>
people wanting to still have a visible fid, and ready to deal with possible <br>
annoyances, could overload this "hidden_fid" value with another value.<br></blockquote><div><br></div><div>This sounds like a simple while powerful solution.</div><div><br></div><div>Matthias<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div></div>