[Qgis-user] File based Geopackage bugs

[Patrick Dunford]

I recall going back someway we were sold this Geopackage idea being 
implemented into Qgis because it was going to be so much better than 
shape files that everyone has been using up to now. I bought into these 
ideas by converting shape files in most of my Qgis projects into 
Geopackage files.

However there appear to be some serious bugs in Qgis' implementation of 
Geopackages as a file based system, and since SQlite has an impeccable 
reputation, it is a reasonable conclusion that there must be significant 
uncorrected bugs in the Qgis code that deals with file based Geopackages.

Here are two examples:

1. Changing the data table associated with a layer, specifically the 
operation of deleting columns, is almost 100% guaranteed to result in 
automatic deletion of 100% of the features in the layer when the layer 
is saved. I have seen this happen multiple times, whether in a layer 
with 92 features or one with half a million.

2. Compared to shapefiles, Geopackages add an extra field called a fid 
which is a unique numerical value. For new records, this value is 
automatically generated. This requirement of uniqueness and the field 
apparently being unchangeable by the end user makes it impossible to 
paste features from another table if the values in the fid field for 
pasted features happen to coincide with existing entries in the table.

These two examples are making me consider changing back to shapefiles in 
all my projects because shapefiles did not cause either of these two 
problems. Supposedly a shapefile is more prone to data corruption. This 
may be the case but as the code in Qgis that deals with shapefiles 
appears to be considerably more mature, these considerations have to be 
reasonably weighed against each other.

Particularly in the case of issue 1, this appears to be a regression 
since I do not recall it being an issue on Qgis 2.18 or possibly earlier 
versions of Qgis 3. (I use the LTS edition of Qgis)