As Jonathan has mentioned, I've expressed my concerns about a similar proposal to drop the FK relationships in the discussion in bug 8369, and I also think that any scheme to refactor the storage of the circ rules must provide a concrete, user-visible improvement. Just reducing the number of table involved is not an adequate reason.
Yes, I would assume a revamped circulation rules editor would be sufficient?
That said, the FKs are only one consideration. Being able to set a general rule for one part of the circ policy (in your example, the loan length) that more specific rules that cover another part (in your example, the maximum number of loans) can fall back on is a change that I *would* see being beneficial: it would allow for circulation policies to be expressed more concisely.
Agreed!
A rule_name/rule_value approach to this, however, may have a maintainability problem: how do you deal with adding a new rule type in the future? I'd suggest, instead, a scheme where a NULL value in a column such as issuelength signals that the next more general rule should be consulted.
Do you mean type is in "maxholds" or "issuelength"? In that case, it would be as simple as create one or more rules with that "rule_name". A fully optional rule can simply be left to non-existence. In my mind, I instead of having rules with a NULL value, they simply would not exist. Does that make sense? Or is it that you mean ccode/branchcode should use NULL instead of * with full key constraints? I think that is an absolute must.
Any scheme to do a major refactoring of the circ rules must, in my view, cover all of the following bases: * a well-defined upgrade path that guarantees that there is no change to effective circulation policy
Agreed, I don't think this would be a difficult one to cover, though it would not simply the rules for those upgrading. They would have to trim their rules by hand, but it would at least mean no change in behavior.
* as always, adequate unit test coverage
Absolutely!
* attention to the user interface for defining circ policy -- if the point of a refactoring is to make it easier to manage circ policies, the UI *must* reflect that
Indeed, this is almost the crux of the issue. I foresee a new for a new paradigm in how to visually represent the circulation policies. Maybe instead of the rules being branch-centric as they are now, they should be rule-centric? Perhaps even a tabbed interface with a tab for each rule?
* ideally, some prototyping of that UI first to check any assumptions that the new version is actually easier to manage
Agreed. I think at least some drawings of a general design would be a good start. Kyle