<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="ltr">
<div dir="ltr">
<div style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<div>Greetings,</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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</div>
<div>installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql</div>
<div>has some NULL and some empty strings.</div>
<div> </div>
<div>So, first question: is that right?</div>
<div> </div>
<div>So, then I thought, “Okay, so where is this # being processed?” I found it around line 1128 in C4/ImportExportFramework.pm which reads:</div>
<div>$data = '' if ($data eq '#');</div>
<div> </div>
<div>So, second question: shouldn’t an empty string have been put out in the first place?</div>
<div> </div>
<div>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.”<br>
</div>
<div>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.</div>
<div> </div>
<div>GPML,</div>
<div>Mark Tompsett</div>
</div>
</div>
</body>
</html>