The constraint might have existed before bug 14069.
For these DB, this patch will restore it, for others, it will add it :)
Test plan:
> show create table issues;
should not return "unique key itemnumber"
Execute the updatedb entry twice
> show create table issues;
should return only one "unique key itemnumber"
Signed-off-by: Marc VĂ©ron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
`issuedate` datetime default NULL, -- date the item was checked out or issued
`onsite_checkout` int(1) NOT NULL default 0, -- in house use flag
PRIMARY KEY (`issue_id`),
+ UNIQUE KEY `itemnumber` (`itemnumber`),
KEY `issuesborridx` (`borrowernumber`),
KEY `itemnumber_idx` (`itemnumber`),
KEY `branchcode_idx` (`branchcode`),
SetVersion($DBversion);
}
+$DBversion = 'XXX';
+if ( CheckVersion($DBversion) ) {
+ my $create_table_issues = @{ $dbh->selectall_arrayref(q|SHOW CREATE TABLE issues|) }[0]->[1];
+ if ($create_table_issues !~ m|UNIQUE KEY.*itemnumber| ) {
+ $dbh->do(q|ALTER TABLE issues ADD CONSTRAINT UNIQUE KEY (itemnumber)|);
+ }
+ print "Update to $DBversion done (Bug 14978: Make sure issues.itemnumber is a unique key)\n";
+ SetVersion($DBversion);
+}
+
# DEVELOPER PROCESS, search for anything to execute in the db_update directory
# SEE bug 13068
# if there is anything in the atomicupdate, read and execute it.