This may be an edge-case, but the existing primary key setup means that if a user raises more than one issue against a record, then only one verification of these can be saved: the rowkey, userId and code (50005 unconfirmed) would all be the same. Verifying another one of the user's issues against the same record overwrites the first one.
Including the relatedUuid field in the primary key fixes this, BUT it means non-verification qa entries must have an empty string ("") relatedUuid, instead of null, since part of a composite key cannot be null.
This may be an edge-case, but the existing primary key setup means that if a user raises more than one issue against a record, then only one verification of these can be saved: the rowkey, userId and code (50005 unconfirmed) would all be the same. Verifying another one of the user's issues against the same record overwrites the first one.
Including the relatedUuid field in the primary key fixes this, BUT it means non-verification qa entries must have an empty string ("") relatedUuid, instead of null, since part of a composite key cannot be null.