An idea for revamping the issuing rules system
Hey all, this is something I've been thinking about for a while now, and I should probably throw it out there to see if it's just a terrible idea ; ) Right now we have 5 tables dealing with circulation rules. I think we can add much greater flexibility *and* simplicity to how we store and select rules. Instead of having the assortment of branch/patron/item, and then the columns for the rules themselves. what if we had just one table with the following schema: branchcode categorycode itemtype rule_name rule_value 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: *, *, *, issuelength, 14 *,*, BOOK, maxissueqty, 20 *,*,DVD, maxissueqty, 5 *,*,CD, maxissueqty, 10 What does everyone think of this idea? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
Hi Kyle, I started something like that 1 year ago (bug 8369 [1]). The problem is we lost foreign key to branchcode and categorycode. I recommend you to read the discussion on this report before starting any development on issuingrules :) Keep informed if you start it! Regards, Jonathan [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8369 2013/11/15 Kyle Hall <kyle.m.hall@gmail.com>
Hey all, this is something I've been thinking about for a while now, and I should probably throw it out there to see if it's just a terrible idea ; )
Right now we have 5 tables dealing with circulation rules. I think we can add much greater flexibility *and* simplicity to how we store and select rules.
Instead of having the assortment of branch/patron/item, and then the columns for the rules themselves. what if we had just one table with the following schema:
branchcode categorycode itemtype rule_name rule_value
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: *, *, *, issuelength, 14 *,*, BOOK, maxissueqty, 20 *,*,DVD, maxissueqty, 5 *,*,CD, maxissueqty, 10
What does everyone think of this idea?
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi, On Fri, Nov 15, 2013 at 7:00 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
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: *, *, *, issuelength, 14 *,*, BOOK, maxissueqty, 20 *,*,DVD, maxissueqty, 5 *,*,CD, maxissueqty, 10
What does everyone think of this idea?
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. 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. 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. 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 * as always, adequate unit test coverage * 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 * ideally, some prototyping of that UI first to check any assumptions that the new version is actually easier to manage Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
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
participants (3)
-
Galen Charlton -
Jonathan Druart -
Kyle Hall