<div dir="ltr"><div>Thanks Nyall for raising this again,</div><div><br></div><div>The way I see it, fid can be seen very similarly to rowid or shapefile fids. A semi-stable unique identifier. Just - and that's the big difference - those are not part of the data hence the system can transparently deal with duplicates and can fill holes once in a while (shp -> repack, sqlite rowid -> vacuum).</div><div><br></div><div>If I could choose I would just make fids disappear (not only from the interface but from all the gpkg implementation). And replace it with rowid if there's a good reason for it (which I still fail to see).</div><div>So just to have brought up the idea: Could we make fids optional for newly created gpkgs. Or is my fear that this will affect interoperability in a bad way correct?<br></div><div><br></div><div>Matthias<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020 at 11:45 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.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">Hi list,<br>
<br>
(Linus Torvalds-style harsh truths incoming, read only after coffee/alcohol!)<br>
<br>
Having spent an incredibly frustrating day fighting with the<br>
limitations of GPKG and the horrible workflow that they mandate, I'd<br>
love to start brainstorming on how we can fix this.<br>
<br>
While previous discussions have related to the GPKG sqlite wal mess,<br>
that has (to the extent of my experience) been resolved in the latest<br>
release. So I'd like to focus on what I see as the biggest pain point<br>
of GPKG: the FID column.<br>
<br>
This is a pain point for numerous reasons:<br>
<br>
- The type constraint on the fid column makes it really hard to<br>
translate datasets with an existing, non-numeric "fid" column into<br>
geopackage. Eg. GML files often have a textual fid string, and<br>
attempting to convert these to gpkg results in a string of errors<br>
about string values not being usable as fid values, and an empty<br>
result layer. The only workaround here is to translate first to an<br>
alternative format (such as shp!), delete the fid column, and THEN<br>
save as gpkg.<br>
<br>
- The fid unique constraint, while understandable, results in a HUGE<br>
raft of issues while working with these. It's SO easy to get a<br>
situation where you have duplicate fids in an edit buffer, and no way<br>
to save these features back to the gpkg. You get a series of 1000s of<br>
errors about duplicate fid, and then an ambiguous state where you're<br>
completely unsure exactly what's been saved and what's about to be<br>
lost. This isn't just attributable to a single tool in QGIS -- it's<br>
possible to end up with duplicate fids through so many different<br>
operations, including really simple stuff like copying and pasting<br>
features!<br>
<br>
I've fought with this since we've really started to push GPKG and,<br>
frankly, I've given up. I don't think there's any way to fix the<br>
current situation and leave fids as they currently behave.<br>
<br>
So what I propose is a radical re-think about how GPKG fids are<br>
handled and exposed by QGIS (and by GDAL).<br>
<br>
I propose that we<br>
<br>
1. demote fids to being only a "semi-permanent" row identifier, with<br>
the message being that "sometimes these WILL change and you can't rely<br>
on them as a permanent id field for joins and row identification". If<br>
users require a permanent unique identifier (i.e. a primary key) on<br>
their table then THEY have to make and manage that themselves, just<br>
like shapefiles etc.<br>
<br>
2. expose fids as a read-only field. Users can still see them if they<br>
want, but they cannot edit them.<br>
<br>
3. make QGIS (or GDAL?) ALWAYS generate a completely new fid whenever<br>
a row is changed or added. Throwaway the old value, make a new one on<br>
EVERY edit/addition.<br>
<br>
4 We COMPLETELY ignore any existing fid value set for features added<br>
to a GPKG layer. I.e. in the case of translating a GML with a text fid<br>
field, we completely ignore the incoming GML fid values and instead<br>
use the "always generate a new fid" rule.<br>
<br>
Yes, these changes will break existing workflows, and possibly break<br>
existing tools/scripts. But honestly, in my experience and the<br>
experience of my customers, there's a COMPLETE lack of faith and trust<br>
in GPKG at this stage. EVERYONE has their horror stories of lost data<br>
and mangled datasets. We've got to do something drastic, and we've got<br>
to do it sooner rather than later to salvage what little hope does<br>
remain for this format.<br>
<br>
Thoughts?<br>
<br>
Nyall<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>