koordinates
Enforce uniqueness of primary key fields at import/commit time
GPKG only supports integer primary keys, whereas a Kart dataset already supports string primary keys. We should be able to adapt one to the other in some way so that you can have a GPKG working copy that is backed by a dataset with string keys - perhaps a dummy integer primary key will be added, and the original string primary key will present in the working copy but not in the primary key column.
Done except there is one more edge case that hasn't been dealt with and could do with some more work:
- what happens if you drop a column in QGIS, which blows away any unique constraints, then start adding non-unique values in the string-pk column?
I'd suggest we add some code to check for dupe PKs at commit time, in the case that the WC isn't enforcing that for us. Throwing a useful error seems like it would adequately fix this problem, something like
mydatasetname: The value 'abc-123' in the "pk" column is not unique. Please fix this and try committing again.
to add to this, even if the WC or import source does normally enforce uniqueness of PKs, you can bypass that by doing kart import --primary-key customfield ..., and kart should check that field for uniqueness.