Bug 10039

Summary: the systempreferences.variable column should be a unique key
Product: Koha Reporter: Galen Charlton <gmcharlt>
Component: Architecture, internals, and plumbingAssignee: Galen Charlton <gmcharlt>
Status: CLOSED INVALID QA Contact:
Severity: enhancement    
Priority: P5 - low CC: dcook, jonathan.druart, m.de.rooy
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Galen Charlton 2013-04-13 17:19:56 UTC
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.
Comment 1 David Cook 2013-04-14 23:30:53 UTC
(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?
Comment 2 Jonathan Druart 2013-04-15 09:25:13 UTC
(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.
Comment 3 Marcel de Rooy 2013-04-15 09:40:15 UTC
(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 :)
Comment 4 Galen Charlton 2013-05-24 17:21:11 UTC
(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.