> I think this is a great idea -- we could retain any compliant fid > values without change, but as soon as we hit a duplicate fid or > non-integer fid value then we discard it and generate a new one. > > What do you think Even?
Are you talking about the addFeatures() method of the provider ? That would be a provider-level change I guess ? Why not, but I'm still puzzled why we need something in the GPKG case and not with PostgreSQL with a integer primary key. One difference I see is that in the GPKG case, when creating features through the GUI, I can set a new feature to a fid value already taken, whereas if I try to do the same with a Postgres layer, the GUI prevents me from doing that. There must be some extra hint that the Postgres provider provides, and GPKG does not. (I can even see that in the same edit session If I try to create 2 features with the same fid value with a Postgres layer, the GUI prevents me from doing that, so before trying any INSERT) Hum, one difference I can see is that QgsOgrProvider::skipConstraintCheck() does not take into account providerProperty( EvaluateDefaultValues, false ) whereas QgsPostgresProvider::skipConstraintCheck() does. And in the QgsOgrProvider::skipConstraintCheck() case, for the fid column, the return of the method will be true ( mDefaultValues being equal to tr( "Autogenerate" ), so not empty ) Interestingly, putting the same implementation as the postgres provider makes GPKG behave as it for the scenarios presented above ! Let's see how CI likes that: https://github.com/qgis/QGIS/pull/39388 Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer