Existing code assumes that the systempreference.variable column is a unique key, but this isn't enforced at the database level. This should be tightened up to avoid potential bugs if multiple rows for the same system preference slip in. One consequence of making systempreferences.variable a UK is that scripts (including upgrade scripts) that insert sysprefs should avoid spurious UK violation errors.
(In reply to comment #0) > Existing code assumes that the systempreference.variable column is a unique > key, but this isn't enforced at the database level. > > This should be tightened up to avoid potential bugs if multiple rows for the > same system preference slip in. > > One consequence of making systempreferences.variable a UK is that scripts > (including upgrade scripts) that insert sysprefs should avoid spurious UK > violation errors. Perhaps I'm confused, but isn't systempreference.variable already the primary key of the systempreference table, which automatically makes it unique? If I look at my DB or kohastructure.sql (at line 2008 of master), it says it's the primary key, and if I try to insert sysprefs using updatedatabase.pl, sysprefs.sql, or manually with a query editor, it always prevents duplication. Am I missing something?
(In reply to comment #1) > Perhaps I'm confused, but isn't systempreference.variable already the > primary key of the systempreference table, which automatically makes it > unique? Same conclusion here, the variable names are already unique.
(In reply to comment #2) > Same conclusion here, the variable names are already unique. These primary keys nowadays are no longer what they used to be :)
(In reply to comment #3) > (In reply to comment #2) > > Same conclusion here, the variable names are already unique. > These primary keys nowadays are no longer what they used to be :) I don't trust them! In the cold light of today, I have no idea why I opened this. I can only assume that I had run into a database that had dropped the PK for some reason.