[Bug 17721] New: Do we need utf8_bin collation on tagsubfield?
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Bug ID: 17721 Summary: Do we need utf8_bin collation on tagsubfield? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt@gmail.com Reporter: m.de.rooy@rijksmuseum.nl QA Contact: testopia@bugs.koha-community.org Comes from report 17676. This discussion should be on a new report. === Comment11
Indeed we want to keep tagsubfield a utf8_bin (to allow lowercase and uppercase of the same letter for subfields). Could you provide an example where we want to do that? Is that MARC conform? And if so(!), why would you need utf8_bin to do so? You can still insert them, only finding the right a or A would be harder. It seems to me that we should remove this strange exception, and make sure that all tagsubfields are saved lowercase. Should not be too hard. Can MARC::Record handle subfields a and A btw? But this discussion should be on a new report.
if ( $table[1] !~ /COLLATE=utf8_unicode_ci/ and $table[1] !~ /COLLATE=utf8mb4_unicode_ci/ ) { #catches utf8mb4 collated tables This is only 99,9% safe (as you are probably aware of). If you find one column in unicode_ci, the table might still be something else (theoretically). Perhaps someone added a custom column with collation? Since you only change the default here, why not always do it? Replacing X with X will not be a problem..
Comment12&13 (Katrin) It's not strictly MARC conform, but we use this a lot and I have talked to others using it as well. Take the 952 field as the example - all subfield codes are taken. Using upper case letters works fantastically now and allows you to store and index data that we got no other sensible spot for. We got it all working perfectly, why break this feature without need? Ah, and I think I have encountered upper case in German MARC - just can't find a documentation right now. === Even if we do not change it at all, it would be worth writing somewhere why we do not. (And where we can still find it later.) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=17676 CC| |jonathan.druart@bugs.koha-c | |ommunity.org, | |katrin.fischer@bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Nicolas Legrand <nicolas.legrand@bulac.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicolas.legrand@bulac.fr --- Comment #1 from Nicolas Legrand <nicolas.legrand@bulac.fr> --- We also use it a lot to describe our items. We have 995a, 995A and so on. I'm not sure it's used with others french library with UNIMARC, but it's a possibility. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 --- Comment #2 from Nicolas Legrand <nicolas.legrand@bulac.fr> --- ha and also no, you can't insert a 995a with a 995A when it's collate=utf8_general_ci and the field is a key because it consider that 995a is the same key as 995A. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Séverine Queune <severine.queune@bulac.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |severine.queune@bulac.fr -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- We need the table or the column to be case sensitive in order to be able to configure, store and retrieve uppercase and lowercase subfields separately. I am no MySQL expert, so can't tell what is the perfect type to use for that use case. Documenting the behaviour is of course always a good idea. A comment in kohastructure.sql maybe? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #3)
We need the table or the column to be case sensitive in order to be able to configure, store and retrieve uppercase and lowercase subfields separately.
I am no MySQL expert, so can't tell what is the perfect type to use for that use case.
Documenting the behaviour is of course always a good idea. A comment in kohastructure.sql maybe?
I am all for a comment at least. As mentioned before, using uppercase subfields is not MARC conform. https://www.loc.gov/marc/96principl.html tells me: === Subfield codes in the MARC 21 formats consist of two characters--a delimiter [1F(16), 8-bit], followed by a data element identifier. A data element identifier may be any lowercase alphabetic or numeric character. === Dont be confused about the delimiter. The last sentence about data element is important. Since many libraries seem to use the concept, we could permit it (somewhat reluctantly). A comment that we use this collation for that reason should be added in kohastructure. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 --- Comment #5 from Nicolas Legrand <nicolas.legrand@bulac.fr> --- I don't see any such limitation in UNIMARC standard. Unfortunately, I don't have a ISO 2709 version right now so I can't check there too. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 --- Comment #6 from Nicolas Legrand <nicolas.legrand@bulac.fr> --- I didn't find explicitly such a limitation in ISO 2709. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Nicolas Legrand <nicolas.legrand@bulac.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=23671 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |REMIND Status|NEW |RESOLVED --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think we have answered the question - if capital subfields are allowed in UNIMARC, we need the case sensitive handling of subfield codes. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org