<div dir="ltr">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.<br><div class="gmail_quote"><div><br></div><div>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).</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>It looks as if we need to keep it as a technical id.</div><div>I like the idea to transparently generate it in addFeature.</div><div>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.</div><div>I hope that makes sense.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Matthias<br></div></div>