participantid, sequencenum, lsid should be NOT NULL

[labkey-matthewb]

Rationale

These were all NOT NULL as designed in the original study.data table. This constraint seems to have been lost over time.

Related Pull Requests

Changes

[labkey-jeckels]

Agreed they shouldn't be null. What happens to existing datasets? Do we need to get this applied to them, and/or somehow fill in existing rows that have nulls?

[labkey-matthewb]

The good news is we enforce that there are no nulls (barring bugs), and things blow up if NULLs get in there (updateParticipantVisits() etc).

I don't know if we need to do anything with existing datasets. This will enforce fast-fail if we have any new (or obscure) bugs.

[labkey-matthewb]

Hmm, teamcity/github seem to be having some syncing troubles.

[labkey-jeckels]

I'm always a bit paranoid about having tables in a variety of states depending on when they were created. @labkey-adam any strong feelings either way in this case?

[labkey-adam]

I agree... I certainly prefer proactive upgrades that ensure consistency

[labkey-jeckels]

@labkey-matthewb I propose that we add these constraints to existing tables at upgrade time, but not try to handle problematic rows in the tables. We can discuss if that represents a sizable chunk of work.