...
// Either or both of accountId and externalId need to be filled out. Would probably use ID column to avoid composite keys, but then would need to verify the results conform to the caller's study and sub-study.
CREATE TABLE `ExternalIds` {
`id` VARCHAR(60) NOT NULL,
`studyId` VARCHAR(60) NOT NULL,
`subStudyId` VARCHAR(60) NOT NULL,
`accountId` VARCHAR(255) NULL,
`externalId` VARCHAR(255) NULL,
PRIMARY KEY (`id`)
UNIQUE INDEX `StudyId-SubStudyId-Index` (`studyId` ASC, `subStudyId` ASC),
UNIQUE INDEX `StudyId-ExternalId-Index` (`studyId` ASC, `externalId` ASC),
UNIQUE INDEX `StudyId-AccountId-Index` (`studyId` ASC, `accountId` ASC)
}
// An outstanding issue is dealing with batch adds... we should probably support that, but not batch deletes.
ExternalIdsServiceV2 {
listExternalIds(studyId, subStudyId, offsetBy, pageSize, includeDeleted)
createExternalId(externalIdObj)
getExternalId(studyId, subStudyId, externalId)
updateExternalId(externalIdObj)
deleteExternalId(studyId, subStudyId, externalId)
deleteExternalIdPermanently(studyId, subStudyId, externalId)
// These would update an add an associate record between Account and SubStudy with an account ID
assignExternalId(studyId, subStudyId, externalId, accountId)
unassignExternalId(studyId, subStudyId, externalId)
}
...