<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 7:00 AM, Kyle Hall <span dir="ltr"><<a href="mailto:kyle.m.hall@gmail.com" target="_blank">kyle.m.hall@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>For example, if every rule right now has a checkout length of 14, but have different max issue quantities, we need to set the checkout length to 14 for each and every combination. With this schema we could have just:</div>

<div><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">*, *, *, issuelength, 14</span></div><div><font color="#000000" face="arial, geneva, helvetica, lucida, sans-serif"><span style="font-size:14px">*,*, BOOK, </span></font><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">maxissueqty, 20</span></div>

<div><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">*,*,DVD, </span><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">maxissueqty, 5</span></div>
<div><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">*,*,CD, </span><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">maxissueqty, 10</span></div>
<div><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif"><br></span></div><div><span style="font-size:14px;font-family:arial,geneva,helvetica,lucida,sans-serif">What does everyone think of this idea?</span></div>
</div></blockquote></div><div class="gmail_extra"><br></div><div>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.</div>
<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><br></div><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><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><br></div><div>* a well-defined upgrade path that guarantees that there is no change to effective circulation policy</div>
<div>* as always, adequate unit test coverage</div><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>* ideally, some prototyping of that UI first to check any assumptions that the new version is actually easier to manage</div><div><br></div><div>Regards,</div><div><br>Galen</div>-- <br><div dir="ltr"><div>Galen Charlton</div>
<div>Manager of Implementation</div><div>Equinox Software, Inc. / The Open Source Experts</div><div>email:  <a href="mailto:gmc@esilibrary.com" target="_blank">gmc@esilibrary.com</a></div><div>direct: +1 770-709-5581</div>
<div>cell:   +1 404-984-4366</div><div>skype:  gmcharlt</div><div>web:    <a href="http://www.esilibrary.com/" target="_blank">http://www.esilibrary.com/</a></div><div>Supporting Koha and Evergreen: <a href="http://koha-community.org" target="_blank">http://koha-community.org</a> & <a href="http://evergreen-ils.org" target="_blank">http://evergreen-ils.org</a></div>
</div>
</div></div>