Summary: | Move fields type, options and explanation from systempreferences table? | ||
---|---|---|---|
Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
Component: | System Administration | Assignee: | Bugs List <koha-bugs> |
Status: | In Discussion --- | QA Contact: | |
Severity: | normal | ||
Priority: | P5 - low | CC: | gmcharlt, nick |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9998 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Marcel de Rooy
2013-05-06 11:45:12 UTC
Hi Marcel, I am not sure what we would win by dividing local use preferences and normal preferences. Both need a table for the value set to be saved, so 2 tables seem more error prone to me than having one with a few columns unused? I am sorry, but I don't understand the point about deleting the pref from your description. Could you give an example where this is a problem? (In reply to comment #1) > I am not sure what we would win by dividing local use preferences and normal > preferences. Both need a table for the value set to be saved, so 2 tables > seem more error prone to me than having one with a few columns unused? Hi Katrin, I agree. If(..) we should move the unused columns, we should leave what we do use in systempreferences. So no completely separate table for local use prefs. Maybe a joined table for options and explanation to remove redundancy? But then we still face this problem: You have local use pref A. Then it becomes a real pref so now its description comes from yaml. But we still have an old description in the joined table.. > I am sorry, but I don't understand the point about deleting the pref from > your description. Could you give an example where this is a problem? This is only a fictive problem. If you would delete a regular pref (remove it from the preferences file), but somehow not delete if from the table (the dbrev did not work out?). In this case you got a local use pref falling back to the old columns. Almost 9 years later... is this something we should still act on? I have to admit, working with a MySQL client often it's nice to have the additional clues in SQL. I am not against changing things, but would personally not push for it. |