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

Zebra facets: yay or nay?
by dcook＠prosentient.com.au 23 May '22

23 May '22

Hi all, Do you use Zebra facets? I think a lot of people have found them very useful for small databases but too slow on larger databases? I noticed how the word "the" could make a difference on a Koha database with 1,000,000+ bib records. Maybe Indexdata can give some insight into that one: https://github.com/indexdata/idzebra/issues/35. I took a look at the Zebra code but I'm neither a C expert nor a Zebra code expert, so nothing obvious jumped out at me. But it seems to me that the facet calculation isn't being done correctly on the result set, as a result set of 3325 records can get 1 facet in 2 records whereas a result set of 3323 records can get 1 facet in 60 seconds (ie too slow to return correctly in Koha). Unfortunately, I don't have a ready-made solution for that one (unlike https://github.com/indexdata/idzebra/issues/34) so I don't know if it'll progress. But fingers crossed! David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Bug 30684: Requesting community feedback on change to restart behaviour of koha-* scripts
by Alex Buckley 20 May '22

20 May '22

Kia ora Koha community, I'd love to hear your thoughts please on adding the following behaviour across all koha-* scripts when passing the --restart parameter: 1. If the service is not running 2. You run sudo koha-<service> --restart <instancename> , e.g. sudo koha-plack --restart kohadev 3. Koha stops the service, then starts it *Context* Bug 30684 was initially written to resolve the below error that is thrown when you try restarting plack, if it's not already running: /[FAIL] Error: Plack not running for <instancename>: failed!/ However, as Marcel noted the error is thrown by design: If you didn't start it, you cannot restart it. So it would be better to stop and then start the service. Also to ensure this change was consistent, it should be implemented in all koha-* scripts, not just koha-plack. Is everyone happy for this change to be implemented in all koha-* scripts? Thanks, Alex

2 1

Plack graceful restart / reload (Bug 21366)
by dcook＠prosentient.com.au 20 May '22

20 May '22

Hi all, For years, we've been talking about providing a graceful restart for Starman. Today, I needed it for a production instance to enable plugins without disrupting anyone's Koha usage, so I ran: kill -SIGHUP $(cat /var/run/koha/<instance name>/plack.pid) It worked so well. I'd be happy to provide a patch, but I imagine there might be some debate about the precise implementation. So if folk could comment on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21366 that would be great. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Time to translate: string freeze to prepare Koha 19.11.30 has begun
by Wainui Witika-Park 19 May '22

19 May '22

Hello, String freeze is into effect as of now for the 19.11.x maintenance branch in preparation for the 19.11.30 release. This means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Happy translating! Wainui Witika-Park (she/her)

1 0

Zebra hot tip #2047 : memMax
by dcook＠prosentient.com.au 18 May '22

18 May '22

Hi all, While trying to tune Zebra for a large Koha library, I ran into some problems when throwing memory at the memMax configuration option. While the documentation says it can use up to half the memory on your system, I've discovered the practical limit is actually 2047MB. Why 2047MB? It's because memMax gets puts into a variable with an "int" data type which is a signed 32 bit integer. If you get to 2048MB or over, you'll end up with invalid values that cause memory allocation issues and your indexing will fail. I've raised an issue with Indexdata to either switch to an unsigned 32 bit integer, switch to a 64 bit integer, or at least add some error checking: https://github.com/indexdata/idzebra/issues/34 But I figured I'd share my little discovery with y'all in the meantime. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

dbic --force
by Tomas Cohen Arazi 18 May '22

18 May '22

Just so you know and because these things frequently go unadvertised: we now have a --force switch in KTD for the `dbic` command. Enjoy. -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

3 2

Analysis help needed for one of the last pieces for ElasticSearch 7 support
by Victor Grousset/tuxayo 17 May '22

17 May '22

Hi :) Bug 25669 has stalled on the choice of two options, it needs a confirmation that one of the alternative patches implements indeed one of the two options which is enough for just ES 7 support and raises no question about additional configuration work unlike the other option. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25669 Bug 25669 - ElasticSearch 6: [types removal] Specifying types in put mapping requests is deprecated (incompatible with 7) Cheers, -- Victor Grousset/tuxayo

1 0

Call for news - Newsletter May 2022
by Koha Newsletter 13 May '22

13 May '22

Hi I'm collecting news for the May 2022 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. Text format criteria: * Just structured plain text, or * HTML text to include tables or similar For events: * Consider adding your event to the Koha Community calendar at https://koha-community.org/calendar/ Thank you! Michael Kuhn Editor, Koha Community Newsletter

1 0

ILS-DI and notforloan status...
by dcook＠prosentient.com.au 13 May '22

13 May '22

Hi all, Recently I opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30636 so that the "GetAvailability" service would correctly show an item as not for loan if set at the item level or item type level. (I notice that the KohaILSDI driver for VuFind uses "GetServices" which already correctly checks both.) However, the discovery layer I'm bumping into is using the "GetRecords" service which just shows the "notforloan" at the item-level only. They've asked for it to be updated to reflect the item type level too, but the way the information is surfaced is more "record" level than availability/action level of those two other services. I'm inclined to make the change to bring uniformity to the services, but can anyone think of a reason not to? I figure I'll just set "notforloan" to 1 if it is not already non-zero and the item type level is set. Sound good? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Koha 22.05 release dates
by Fridolin SOMERS 11 May '22

11 May '22

Hi dear community, Here is the timeline for the 22.05 major release: * April 29 - "Soft" feature freeze : nothing big or with high risk of side-effects will be included into the final release if not marked as Passed QA * Mai 6 - "Hard" feature freeze : nothing considered as an improvement will be pushed if not marked as Passed QA * Mai 11 - String freeze : draft of release notes published * Mai 18 - Beta : Only bug fixes considered major, critical or blocker will be pushed * Mai 26 - Final release Let me know if you have any request ;) -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

4 6