Greetings,

I was looking to sign off bug 18111, which looks good by the way, and then I 
noticed that ods and xml exports were floody. So, I was pondering how to fix 
them, because the code is reminiscent of MARC indicators and not 
authorised_value or framework code. So, I put in a condition to catch things 
and make it not floody, but then my exports were strange. Some had ‘#’ and some 
had ‘’ in the authorised_values. This, of course, didn’t match the CSV patch in 
bug 17389. And regardless of format, I would expect the same values in the 
columns.

So I thought, “Why are some #’s and some blank?” Turns out marc_tag_structure 
has both NULL and empty strings in the authorised_value field. I thought to 
myself, “Where did this get set?” I had recently dropped and recreated my 
database, so it had to be an installer file. Well, it turns out that
installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql
has some NULL and some empty strings.

So, first question: is that right?

So, then I thought, “Okay, so where is this # being processed?” I found it 
around line 1128 in C4/ImportExportFramework.pm which reads:
$data = '' if ($data eq '#');

So, second question: shouldn’t an empty string have been put out in the first 
place?

To which I thought, “Bah! It works. It’s ugly and gross and should be 
refactored somehow, but I don’t know which way, so I’ll just leave it.”
So, last question: if you were going to refactor, what would your plan of 
attack be? This includes choosing not to refactor as an option.

GPML,
Mark Tompsett
_______________________________________________
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/

Reply via email to