[Koha-bugs] [Bug 24594] Rewrite MARC21 mandatory data to YAML

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Mar 4 17:04:23 CET 2020


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24594

--- Comment #6 from Bernardo Gonzalez Kriegel <bgkriegel at gmail.com> ---
Hi Jonathan, my reply

(In reply to Jonathan Druart from comment #5)
> 1. There are some QA issues:
>  FAIL  
> installer/data/mysql/en/marcflavour/marc21/mandatory/
> authorities_normal_marc21.yml                                               
> 
>    FAIL   yaml_valid                                                        
> YAML Error: Inconsistent indentation level                                  

Yes, I was aware of this, I left notes on the commit messages.
Current QA test uses YAML.pm, it considers as valid this:
---
data:
  - "a b c d"
...
but not this:
---
data:
  - "a b 
     c d"
...
however it is valid :(

The problem arises in some multiline sql_statements. The solution is to put
them as long single lines. It makes readability difficult, but I can do it.
Using YAML::Sick or YAML::XS gives no error, but implies changes in QA tools.
As I said, I can change them if you prefer.


> 
> 2. I did an install 'en' before and after the patchset, I mysqldump --tab to
> generate 2 files per table, then compared the 2 generated directories with
> `diff -r --brief` (and also a `perl -p -i -e "s/.*Dump completed.*//" **/*`
> to remove timestamp of the dump).
> Most of them are wrong diff because of different timestamps, but some of
> them are either weird, or caught issues:
> 
> a) When a row is on several lines, I get, for instance with letter
> "TO_PROCESS":
> 652,657c652,657
> \ suggestions	TO_PROCESS		Notify fund owner	0	A suggestion is ready to be
> processed	Dear <<borrowers.firstname>> <<borrowers.surname>>,
> \ 
> \ A new suggestion is ready to be processed: <<suggestions.title>> by
> <<suggestions.author>>.
> \ 
> \ Thank you,
> \ 
> ---
> > suggestions	TO_PROCESS		Notify fund owner	0	A suggestion is ready to be processed	Dear <<borrowers.firstname>> <<borrowers.surname>>,\
> > \
> > A new suggestion is ready to be processed: <<suggestions.title>> by <<suggestions.author>>.\
> > \
> > Thank you,\
> > \
> 
> Without the patch:
> 656 Thank you,\
> With the patch:
> 656 Thank you,^M\
> 
> I am not sure how relevant is this, the UI looks correct.

Some of the sample notices where clearly generated in Windows, I assume this
because they have '\r\n' for newlines. Some others not.
So I decided to join all multiline fields with both chars. I left a comment on
the last patch of Bug 13897
"'\r\n' is used for correct display in Windows clients."
in the code 
"? join "\r\n", @{$row->{$col}}                # join multiline values"

The diff you see comes from those notices that originally have only '\n' for
newlines.

> 
> b) matcher_matchpoints is different:
> without:
> 1 1
> 2 2
> 3 3
> with:
> 3 1
> 3 2
> 3 3

Yes, my bad. The sql_statements make use of MAX() to insert values, then the
result depends on the order of insertions.
I will add a followup to Bug 24593 to fix the problem.

> 
> d) subscription_numberpatterns (to investigate)
> 
> 1c1
> < 1	Number	1	Simple Numbering method	No. {X}	Number	1	1	99999	1	\N		\N	\N	\N
> \N	\N		\N	\N	\N	\N	\N
> ---
> > 1	Number	1	Simple Numbering method	No. {X}	Number	1	1	99999	1	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N
...
> 

The difference in this case comes from the values of label2 & label3 fields.
In the SQL files some of these fields are NULL, in YAML they can't because they
are translated, and the translate script will fail, so I put on them an empty
string "". I think that this change does not affect the numbered patterns.
If a NULL value is needed, then I must change the translate script
(LangInstaller.pm)


> e) systempreferences (to ignore)
> There is an obvious change here on "FrameworksLoaded", the list of sql files
> is replaced with a list of yml files.
> I did not know this pref existed, it seems to be used to make sure we are
> not going to load twice the same files.
> We can ignore this one.

Ok!

Summary:
1) Can be rewritten to single lines if needed
2a) I think is not a problem
2b) Followup uploaded to Bug 24593
2d) Waiting your opinion

Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list