<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im">
<div class="gmail_extra"><span style="color:rgb(34,34,34)">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.</span></div>
</div></div></div></blockquote><div><br></div><div>Yes, I would assume a revamped circulation rules editor would be sufficient? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra">
<div><br></div><div>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.</div>
</div></div></blockquote><div><br></div><div>Agreed!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div>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.</div>
</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div><br></div><div>Any scheme to do a major refactoring of the circ rules must, in my view, cover all of the following bases:</div><div>* a well-defined upgrade path that guarantees that there is no change to effective circulation policy</div>
</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div>* as always, adequate unit test coverage</div></div></div></blockquote><div><br></div><div>Absolutely!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div>* 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</div></div>
</div></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div>* ideally, some prototyping of that UI first to check any assumptions that the new version is actually easier to manage</div></div></div></blockquote><div><br></div><div>Agreed. I think at least some drawings of a general design would be a good start.</div>
<div><br></div><div>Kyle</div></div></div></div>