- Koha-devel - lists.koha-community.org

Benchmarks - prior to the 3.22 release
by Jonathan Druart 01 Dec '15

01 Dec '15

Hi devs, Please have a look at the these benchmarks: http://wiki.koha-community.org/wiki/Benchmark_for_3.22 I let you draw the appropriate conclusions. Cheers, Jonathan

4 12

Debugging in vim
by Barton Chittenden 01 Dec '15

01 Dec '15

Hi, has anyone gotten debugging to work in vim, using the instructions here? http://wiki.koha-community.org/wiki/Debugging_in_VIM I tried it, and ran into dependency hell... If I remember correctly, Komodo-PerlRemoteDebugging-4.4.1 didn't play nicely with https://github.com/joonty/vdebug. If someone *has* gotten this working, I'd like to know how it was done, so that I can update the wiki. Thanks, --Barton

3 2

Re: [Koha-devel] Proposed "metadata" table for Koha
by David Cook 30 Nov '15

30 Nov '15

For now, I think the metadata.record_id would link to biblionumber, but long-term it would probably link to some “record” table. So if you wanted to get all bibliographic records, you’d do something like: select * from record join metadata ON record.id = metadata.record_id where record.type = ‘bibliographic’ Or maybe you want to search for a bibliographic record with a 001 of 123456789: select * from record join metadata ON record.id = metadata.record_id where record.type = ‘bibliographic’ and metadata.qualifier = ‘001’ and metadata.value = ‘123456789’ -- Of course, off the top of my head, I don’t know how you’d store indicators and subfields in an extensible way. I suppose indicators are attributes and subfields are child elements... I suppose DSpace actually does a “element” and “qualifier” approach for DC. So you’d have a “dc”, “author”, “primary”. Or “marc21” “100” “a”. Of course, that creates a limit of a single level of hierarchy which may or may not be desirable… and still doesn’t account for indicators/attributes. I suppose there is more thinking to do there. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Barton Chittenden [mailto:barton@bywatersolutions.com] Sent: Monday, 30 November 2015 2:17 PM To: David Cook <dcook(a)prosentient.com.au> Subject: Re: [Koha-devel] Proposed "metadata" table for Koha > The basic schema I have in mind would be something like: metadata.id <http://metadata.id> , metadata.record_id, metadata.scheme, metadata.qualifier, metadata.value. > > > > The row would look like: 1, 1, marc21, 001, 123456789 I think this is an interesting idea... Obviously the replication of biblio data is not ideal, but I think that that's a necessary and worthwhile trade off in terms of moving away from MARC. How do you propose linking the metadata fields to the biblio records? Does the metadata.record_id link to biblionumber?

3 2

Koha Community Newsletter: November 2015
by Koha Newsletter 30 Nov '15

30 Nov '15

Fellow Koha users: The Koha Community Newsletter for November 2015 is here: https://koha-community.org/koha-community-newsletter-november-2015/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! Chad Roseburg Editor, Koha Community Newsletter

1 0

Koha 3.22 released
by Tomas Cohen Arazi 27 Nov '15

27 Nov '15

It is with great pleasure that we announce the release of Koha 3.22, a major release of the Koha open source integrated library system. Koha 3.22 is a major release, that comes with many new features. See the full release notes here: https://koha-community.org/koha-3-22-released/ Download: http://koha-community.org/download-koha/ Debian packages for this beta will be available soon on the unstable repository. Thanks everyone! -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

7 6

Indexes of Physical presentation
by Fridolin SOMERS 24 Nov '15

24 Nov '15

Hie, In intranet search, physical presentation uses index ff8-23. In opac search, physical presentation uses index Material-type. This is strange because the search always use the coded values, meaning it is ff8-23 the correct index. Do you agree ? Regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

3 5

Problematic Zebra Charmaps Equivalences
by David Cook 24 Nov '15

24 Nov '15

Hi all: Yet another Zebra email from this guy. I don’t know how many of you are using CHR vs ICU, but CHR is the default for installs, so I’m guessing that it’s quite a few. Well, there are some issues with how we use the equivalent directive. Hopefully the UTF-8 won’t be stripped out of this message, although I’m guessing it might… Here’s all instances of the directive in word-phrase-utf.chr: # Characters to be considered equivalent for sorting purposes equivalent aáàãåâăąȧǎȁȃ equivalent ӕä(ae) equivalent ā(aa) equivalent iíìîịĩĭįǐȉȋ equivalent ï(ie) equivalent ī(ii) equivalent uúùûũŭųűǔȕȗ equivalent ü(ue) equivalent ū(uu) equivalent eéèêẽĕęėěȅȇ equivalent ëē(ee) equivalent oóòõôŏǫȯőǒȍȏ equivalent Œœöø(oe) equivalent ō(oo) Firstly, that comment is wrong. “equivalent” isn’t just for sorting purposes. It’s for searching purposes. Indexdata have confirmed that the documentation is wrong about the sorting thing. So “ie” and ï (if you can’t see this character, it’s the UTF-8 representation of ï) are equivalent. That means searches for “siemon” will get results for “siemon” and “sïmon”. Now, there is also a “map” directive: map ï i This means that “sïmon” is the same as “simon”. Now, “map” affects both indexing and searching. If you have “sïmon” in a record, you can see that it is actually stored as “simon” in Zebra, if you do a search for it and use “format xml” and “elements zebra::index”. So your search for “siemon” will really get results for “siemon” and “simon”. This really isn’t ideal. However, you can see why you’d want equivalences. In Scandinavian languages, I think “å” and “aa” are roughly equivalent. They’re spelled differently but they’re the same sound. So if you search for “Gaard”, you might want hits for “Gård” as well. But you might not want “career” to be equivalent to “carer” as they’re two different words. Or “choose” to be equivalent to “chose”, “sloop” - "slop”, “reef” - "ref”, etc. -- Unfortunately, I don’t really know what the solution is. For one client, I’ve disabled the equivalent directive where it creates an equivalence between any two letter combination with a one letter combination, as they only have records in English, and it’ll just cause them headaches. I can see this being useful for multilingual records… although I think many people with multilingual records use ICU. I don’t know ICU well enough to know how it manages characters that English speakers would think of as accents or ligatures. I know you can provide your own normalization with ICU, but I think it does a fair amount on its own as well… I think some of the difficulties are mentioned here: http://userguide.icu-project.org/collation/icu-string-search-service. It also mentions the Danish å/aa example. I don’t know how ICU would know how to handle particular languages… that webpage seems to indicate you can provide a locale to deal with it. Of course, that doesn’t necessarily solve things. If you have multilingual records with multilingual users, how do you choose your rules? Sure, you might be able to specify a locale at search time (note you can’t do this with Zebra), but what rules did you specify at index time? As anyone who has watched this video (https://www.youtube.com/watch?v=0j74jcxSunY) would know, internationalis(z)ing code has many challenges… -- Anyway, the reason for this email is mostly just to make you all aware of this issue, and how “equivalent” and “map” work in the Charmap files when using CHR indexing. Oh, also, if you look at “default.idx”, you’ll see that “sort s” references “charmap sort-string-utf.chr”, but I don’t think sort-string-utf.chr actually exists anywhere… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

3 3

Help about bug 15207
by Zeno Tajoli 21 Nov '15

21 Nov '15

Hi to all, I trying to resolve bug 15207, Error on upgrade from 3.20.5 to 3.22 beta http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15207. The second error (insert defaults in the table 'permissions') it easy, I change 'INSERT' with 'INSERT IGNORE' and all is OK. The first one is much more difficult: insert a CONSTRAINT but if you update from 3.20.5 this CONSTRAINT is just present. I don't find a similar situation in others parts of installer/data/mysql/updatedatabase.pl I try a solution (check the presence of the CONSTRAINT using information_schema.table_constraints) but it doesn't work always. For example it doesn't work for Katrin. I don't know what to do now. Do you have any idea about this topic ? Bye Zeno Tajoli

2 1

About level of collaction in MySQL
by Zeno Tajoli 21 Nov '15

21 Nov '15

Hi to all, working on bug 15207, Error on upgrade from 3.20.5 to 3.22 beta, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15207 Bernardo finds same missing bit about collate info in sound alerts table and he propose a patch about it. As I see collate info are not mandatory for us at column or table level, we setup it at database level. I see that mysql works with levels to define collation [server, database, table, column]. So which level of collation do we want ? Bye Zeno Tajoli

1 0

E noho rā, Koha
by Robin Sheat 20 Nov '15

20 Nov '15

Hi, Koha folks. Tomorrow is my last day at Catalyst, and the end of my last week in New Zealand. From December, I'm starting a new job that is located only 1,450km distance from as far away as it is possible to get from Wellington on earth. That is, in Amsterdam*. It's been a pleasure meeting those of you that I've met, emailing and IRCing those that I haven't, and I'm sure you'll all keep the project heading on its current course to taking over the world :) Interesting note: my first commit was on April 20th, 2010, signed off by Galen, who has happily taken over my package manager role with almost no blackmai^Wbriber^Wconvincing needed. I'll probably still be lurking in IRC though, just in a quite different timezone to what it was, and skimming emails trying not to answer them. Ka kite anō au i a koutou, -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF * Marcel, I'm going to have to get you to show me the Rijksmuseum library some time :)

5 4