Bug 6931 - hardcoded insert incompatible with UNIMARC
Summary: hardcoded insert incompatible with UNIMARC
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: 3.6
Hardware: All All
: P5 - low major (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
Depends on:
Reported: 2011-09-28 16:01 UTC by Paul Poulain
Modified: 2013-12-05 20:04 UTC (History)
4 users (show)

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

Bug 6931 : Only update frameworks for the correct marcflavour (2.40 KB, patch)
2012-04-19 21:53 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Poulain 2011-09-28 16:01:00 UTC
In updatedatabase, the $DBversion = "";
contains :
    my $sth = $dbh->prepare("INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, 
                             `tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`)
                             VALUES ( ?, '9', '9 (RLIN)', '9 (RLIN)', 0, 0, '', 6, '', '', '', 0, -5, '', '', '', NULL)");

=>> it's marcflavour independant and will result in some pain in UNIMARC ! (648...662 should not exist in standard UNIMARC so, 1- dead data will be added and 2-if a library uses those fields for local use, that will break a lot of things (ie : the 6xx are used for authorities, the $9 for authid, so, I don't imagine what the result will be !)

A simple if syspref("marcflavour") eq "marc21" before the insert should fix the bug
Comment 1 Katrin Fischer 2012-03-19 06:04:26 UTC
It seems this wasn't fixed :( Perhaps still worth fixing for libraries updating from older versions?

3976 $DBversion = "";
3977 if (C4::Context->preference("Version") < TransformToNum($DBversion)) {
3978     my $sth = $dbh->prepare("INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, 
3979                              `tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`)
3980                              VALUES ( ?, '9', '9 (RLIN)', '9 (RLIN)', 0, 0, '', 6, '', '', '', 0, -5, '', '', '', NULL)");
3981     $sth->execute('648');
3982     $sth->execute('654');
3983     $sth->execute('655');
3984     $sth->execute('656');
3985     $sth->execute('657');
3986     $sth->execute('658');
3987     $sth->execute('662');
3988     $sth->finish;
3989     print "Upgrade to $DBversion done (Bug 5619: Add subfield 9 to marc21 648,654,655,656,657,658,662)\n";
3990     SetVersion ($DBversion);
3991 }
Comment 2 Chris Cormack 2012-04-19 21:53:35 UTC
Created attachment 9264 [details] [review]
Bug 6931 : Only update frameworks for the correct marcflavour
Comment 3 Chris Cormack 2012-04-19 21:54:37 UTC
This bug will still effect anyone coming from 3.2.x or previous, of which there are still hundreds of libraries.

So i think the fix is worth doing.
Comment 4 Paul Poulain 2012-04-20 14:34:21 UTC
patch is OK
Comment 5 Paul Poulain 2012-04-20 14:36:15 UTC
QA comment: trivial patch. However, one question for magnus: are those fields relevant in NORMARC ? Shouldn't we use unless $marcflavour eq 'unimarc' ?

I'll push the patch, because it fixes a very annoying bug for UNIMARC users.
Note that, if you think there are no NORMARC libraries using 3.2 now, you shouldn't care for this patch !
Comment 6 Magnus Enger 2012-04-23 14:18:43 UTC
Of these fields, NORMARC only uses 655, 656 and 658. In all of those subfield 9 is used for some kind of language information, and this is already defined for the frameworks in Koha. So updating subfield 9 the same way it's done for MARC21 here would not be a good idea. 

Of course, this will spell trouble for NORMARC libraries wanting to use authorities, but I think we'll tackle that when (and if) we get there. Hopefully NORMARC will be obsolete before that... ;-)
Comment 7 Jared Camins-Esakov 2012-12-31 00:54:54 UTC
There have been no further reports of problems so I am marking this bug resolved.