Bug 2189 - Hard coded template field constraints allow bugs to persist
Summary: Hard coded template field constraints allow bugs to persist
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: rel_3_0
Hardware: All All
: P3 normal (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-02 12:50 UTC by Chris Cormack
Modified: 2014-12-07 20:02 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:47:35 UTC


---- Reported by kohabugs@agogme.com 2008-06-02 00:50:28 ----

1.  PROBLEM.

All the templates have field sizes hard coded to the size expected by the data to be filled in accordance with the maximum size specified by a database column at the time a particular part of the template was written.  They may also have other constraints as originally specified for the column.  This inflexible design has caused unreported bugs and prevented other unreported bugs from being fixed in the past.  Additionally, this design restricts the flexibility of merely modifying an SQL column to accommodate an additional standard or local need.


2.  EXAMPLES.

2.1.  LIBRARY ORGANISATION CODES.

In Koha 2.X, branchcode had been defined as CHAR(4).  This prevented the use of standards compliant organisation names in branchcode.

Many libraries have organisation codes assigned by the Library of Congress which often exceed 4 characters in length.  For MARC 21, this issue may have been less important as no attempt was made to conform to MARC 21 holdings standards.

Many French libraries have Registre des bibliothèques du catalogue collectif national (RBCCN) organisation codes assigned by ABES for the centres régionaux du catalogue collectif national des publications en série (CCNPS) which all exceed 4 characters in length.  Koha has claimed to have adapted Recommandation 995 for UNIMARC in France but the Recommandation 995 standard specifies a 9 digit RBCCN which is contemplated for expansion to 10 digits.

In Koha 3.0, branchcode has now been defined as VARCHAR(10).  The current size should accommodate the current LC and RBCCN organisation codes.  However, suppose RBCCN is changed to an 11 digit code instead of the contemplated 10 digits.  More importantly, other types of organisations which use longer organisation codes may have a use for Koha.

Furthermore, a library may choose to add a standards non-compliant extension to a standard organisation code which had only been assigned for the library as a whole but not the separate branches or for use in virtual branches designating special collections within a particular branch.  While using any arbitrary code may be possible when deviating from standards, extending existing standards is more semantically meaningful when it is necessary to examine the raw record data. That need may be outside the context of the templates, such as correctly applying some batch processing tasks for records when branchname will not be present in the interface, yet the templates still need to accommodate the size of the organisation code used in the first place.

The only Koha code which restricts the size of organisation codes to my knowledge is the hard coding in the templates.  Developers and users should not need to change anything more than the branchcode column sizes to accommodate a new standard or a local need for a longer organisation code.


2.2.  FRAMEWORK CODE.

In Koha 2.X, frameworkcode is defined as CHAR(4) and authtypecode is defined as CHAR(10).  This has prevented semantically meaningful naming conventions for the bibliographic frameworks.  While frameworktext needs to be meaningful for librarians, frameworkcode should still be meaningful to programmers and may need to accommodate some deep technical distinctions which should not clutter frameworktext for librarians.  There are no proper standards for framework codes, but the codes should still be easily readable to avoid bugs.  Why do authority frameworks need a more easily read naming convention of 10 characters than bibliographic frameworks with only 4 characters.  (A more flexible frameworks design is needed generally, which would solve the issue with respect to frameworks, but that would require a giant effort rather than the modest effort for fixing the templates field constraint problem generally.)

I once increased the column sizes of bibliographic frameworkcode to adopt a readable naming convention corresponding to what the frameworks actually represent in MARC 21.  Changing frameworks in the record editor did not function correctly for frameworkcodes longer than 4 characters because the template truncated the codes which were longer than that.

In Koha 3.0, frameworkcode is defined as VARCHAR(4) and  authtypecode is defined as VARCHAR(10).  I would have increased the size of at least frameworkcode long ago if I did not also have to make a corresponding change wherever it might be used in the templates.


2.3.  OTHER EXAMPLES.

The examples above are trivial compared to the ways in which users may imagine customising Koha for a particular purpose.  New features could be added merely by extending the possible values for a column and some interpretive code for the additional values.  The modifier should not need to change all the relevant templates in every instance of a pre-existing column for extending the functionality.  Needing to change the templates in every instance is merely an obstacle to development.  Hard coding values is usually a bad idea and should be avoided wherever it can be.


3.  SOLUTION.

Rather than using hard coded field sizes and types, templates should read the actual SQL column definitions in use for the particular database as web pages are built and constrain input accordingly.  Such a simple elegant design should both increase the flexibility of Koha to accommodate new uses and reduce the burden of maintaining the templates.



---- Additional Comments From kohabugs@agogme.com 2008-06-04 10:37:33 ----

I had not adequately considered the absolute number of fields affected by my suggestion of how to solve the problem dynamically in real time.  This bug is not known to be related to any other current 3.0 bugs so I have appropriately lowered its severity.

There are a very few columns which one can readily predict that at least some local Koha implementers would want to expand beyond their current limits for ease of administration if not for standards compliance.  I will identify those few columns and suggest that their maximum length be increased to 32 in the database.  Hard coding them with a maximum size of 32 should be sufficient for the templates.



---- Additional Comments From oleonard@myacpl.org 2009-05-02 19:58:53 ----

Changing component. The scope of this bug is far beyond just templates.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:47 UTC  ---

This bug was previously known as _bug_ 2189 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2189

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was kohabugs@agogme.com.
CC member bchurch@ptfs.com does not have an account here

Comment 1 Mirko Tietgen 2012-12-16 13:18:46 UTC
Promised follow-up information did not arrive on bugzilla. Changing this to resolved-wontfix.