https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #9)
This is really for multi branch sites that need more granularity. Minor things like the default MARC organization code are defined globally and then overridden with a new column in 'branches'. This pattern can be problematic in my opinion, handling it on a per-case basis.
And adding columns everywhere we want to make a syspref overridden per-branch looks worse than NULL values.
Those are good points. I've wondered a bit about branch_configurations, item_configurations, and patron_configurations, but then there are times when you need combinations of all 3, so having just one configurations table as you've done does make sense. Something about the configurations table *feels* wrong though. That said, maybe it's just my mind trying to prematurely optimize. I suppose even if you had 1000 library branches, so long as you indexed by branch, patron category, and item type... you could do a lookup pretty easily. So scale shouldn't be an issue. And having 1 big table versus smaller tables or configuration files makes it easier to add new configuration options (although possibly with a downtime cost at upgrade time for adding columns to all existing rows if you have a large configurations table but I doubt the configurations table would ever grow that large, and if it did then we could split it out more at that point). I suppose I can't think of any good reason not to do a "configurations" table. -- You are receiving this mail because: You are watching all bug changes.