Consider using natrual keys on the Election model

[symroe]

In some situations the sync_elections command can fail because it uses pk look ups at the same time as election_id being unique.

The root problem is some other process failing, but it might be worth trying Django's natural_keys to prevent the importer failing for this class of data consistency problem.

To do this we would need to implement natural_key() on the model and get_by_natural_key() on the manager.

[symroe]

Alternatively, convert election_id to be the PK on the Election model.

[chris48s]

Now we don't need the temp ids, I think it makes more sense to make election_id the PK. Note that this major DB change will require us to re-deploy any 'client' installs at the same time as the main instance.

[chris48s]

Had a really quick look at this to see if we can just change it and rely on django unicorns to magically sort it out. tl;dr: everything broke.

It seems that if you change the PK on a table, django doesn't automatically update FK fields. Fortunately I think the only FK we have to election_id is group_id but it looks like we need to write a series of manual migrations to do something like (pseudo-code):

• drop group_id FK constraint
• CREATE COLUMN group_id_new STRING;
• UPDATE elections SET group_id_new=(SELECT election_id FROM elections WHERE election_id=group_id);
• run generated django migration to switch keys over
• DROP COLUMN group_id;
• RENAME COLUMN group_id_new TO group_id;
• add group_id FK constraint

err.. needs some testing