Changing pk column is not supported

[olsen232]

In the V2 structure, changing which column is the primary key means that every feature has to be deleted and rewritten in a new location.
Preliminary tests indicate this works to some extent, but definitely the diff shown for this change will be useless. We need to do more work if we want to support this properly.

[olsen232]

This actually seems to work about as well as can be expected. Kart treats a feature as the same if it has the same primary key - all primary keys changing at once means everything old was deleted, and everything new is newly inserted. But, that's consistent with how kart works.

[olsen232]

This is not done, so closing this bug was an oversight.
The limited but reasonable-considering-Kart's-model behaviour described above does happen if you manage to create a commit where the primary key changes. This is possible to do using kart import which is okay with such changes.

It is not possible to create such a commit by modifying the working copy, since there is a check preventing it. Attempting to modify the working copy to change the primary key column will fail at the commit-step with "Schema changes that involve primary key changes are not yet supported".

Fixing this so that it works just as it does at import-time is of course possible, but will just need to take an extra step of explicitly deleting every pre-existing row from the model and explicitly adding every current row from the working copy during any commit which changes the primary key, since the DB operation which changed the primary key won't necessarily have caused every single row to be marked as dirty, but every row is dirty since it potentially (probably) has a new PK value and so needs to be deleted from one path and rewritten at another path.

Note that changing primary key type from int to text or vice versa would also require that the path metadata is rewritten, which is also not yet implemented.