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

DateUtils / Zebra
by Paul A 14 Dec '15

14 Dec '15

(I found one email, no response, from 21 May 2014 on this subject; can't find anything 'DateUtils' with either 'Zebra' or 'catalog' in bugs.koha-community.org.) It's extremely rare nowadays that we do a complete re-index on the production servers, but I did one today after a direct (naughty me) tweak to MySQL (frameworks/itemtypes) to avoid a lengthy sandbox<==>production to and fro. I got the following: koha_account@my_production:/usr/share/koha$ ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x given is experimental at /usr/share/koha/lib/Koha/DateUtils.pm line 114. when is experimental at /usr/share/koha/lib/Koha/DateUtils.pm line 115. when is experimental at /usr/share/koha/lib/Koha/DateUtils.pm line 118. when is experimental at /usr/share/koha/lib/Koha/DateUtils.pm line 121. Smartmatch is experimental at /usr/share/koha/lib/C4/Search.pm line 492. Useless use of '\'; doesn't escape metacharacter '(' at /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 917. Just thought I'd ask if anyone has any thoughts on this as I'm fairly sure I've never seen it before -- note, it doesn't *appear* to hurt anything. Tnx and regards -- Paul

2 1

Form input handling
by Martin Persson 13 Dec '15

13 Dec '15

Hello, I was just wondering how new code should handle form input processing? Is there a recommended CPAN module that I can use, or should I simply perform validation and transformations by hand? Best wishes, Martin Persson

1 0

Updates for 3.24
by Brendan Gallagher 12 Dec '15

12 Dec '15

Hi All - I just got back from Asia and it was a lovely trip. While I was gone, Kyle pushed some bugs for us and only concentrated on bugs without string changes. This next week coming up - I will begin to concentrate on pushing bugs with strings changes, and that still leaves us at a target for pushing enhancements starting in January. Personal note I will be working different hours than my normal hours (traveling a little bit but all within US). Thanks all, Brendan

1 0

Re: [Koha-devel] [Koha] Problem with BarcodeFallbackSearch
by Paul A 11 Dec '15

11 Dec '15

At 03:56 PM 12/10/2015 -0500, Galen Charlton wrote: >Hi, > >On Wed, Dec 9, 2015 at 6:46 PM, Paul A <paul.a(a)navalmarinearchive.com> wrote: > > Enhancements, improvements and new features: a good starting point is the > > user list, (IRC?) and possibly the dev list. If there is consensus, this > > should be filed at ??? <enhancements.koha-community.org> (similar to > > bugzilla) > >It is hardly unusual for a "bugs" database to be used to record both >reports of defects with the software and requests for enhancements. >The Koha project has done so for years; procedures for doing are >documented in the project bug reporting guidelines [1]. Hi Galen -- thanks for the reply. I agree that overlap is unavoidable and that there are many reasons to "combine" rather than have two databases, which was why I tried to differentiate between "existing code has a problem" and "future code could improve Koha." My reflections on the matter were prompted by my inability (perhaps I'm missing something?) in Bugzilla to find bugs by "severity." Example, the detailed search for all "major" bugs (in whatever state of advancement barring 'unconfirmed', 'resolved' and 'closed') comes up with 211 results; "critical" is more manageable at 35 results. Add to that the tricky problem of security bugs (publish on knowledge of them? publish when fixed? not publish at all?) My gut feeling is that public discretion is advisable until "sorted out", but I'm not sure what the policy of koha-community might be. Some openness with confirmed sys-admins would surely be a good idea, but there's no "search/system" way at <http://bugs.koha-community.org> e.g it takes a bit of fiddling to find 9569, and I have little or no idea what else there might be (if anything.) Best -- Paul

1 0

DOM indexing performance
by Fridolin SOMERS 11 Dec '15

11 Dec '15

Hie, We have on a machine big performance issues since indexing was changed from GRS1 to DOM. I have made some benchmarks, looks like indexing time is more than twice longer. When there is a lot of circulation, the indexing of zebraqueue can take more than a minute. We know that this machine is not powerful regarding RAM and disk, but it was enough until now. Does anyone have the same problem ? The point is not to come back to obsolete GRS1, but is there a way to optimize DOM indexing ? My tests shows facets indexing does not change a lot. -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

7 6

Re: [Koha-devel] [Koha] Problem with BarcodeFallbackSearch
by Paul A 10 Dec '15

10 Dec '15

At 10:36 PM 12/9/2015 +0100, someone wrote: >El 09/12/15 a las 22:13, someone else escribiÃ³: > > If this is a desirable feature, a good place to start would be to file a > > bug at http://bugs.koha-community.org. :) That's from the "user" list, and while some of you consider me $whatever, I have concerns regarding the use of the term "bug" that I genuinely believe to be in the best interest of koha-community. "A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." (Wikipedia) 'bugs' -- quantifiable shortcomings in software 'issues' -- potential problems that aren't directly to related code e.g.design decisions 'enhancements' -- ideas that haven't been implemented yet. 'security' -- must be considered separately; breaches are fundamental, not bugs. If backwards correction is not possible, this must be announced. "Security by obscurity" is a fallacy. Suggest[1]: If you are: a) Requesting a new feature (enhancement), or b) Having build problems, or c) Not sure what the behavior should be, or d) Disagreeing with current intended behavior, or e) Not TOTALLY sure that others would agree this is a bug, or f) For any reason at all not sure this should be filed, ...then please post to the dev list first. You'll get a faster response, and others won't be forced to use the bugs.koha database to have the initial real-time conversations. Nothing is lost this way. If it is eventually concluded that it is a bug, then we can still file it later, after the description and reproduction recipe have been honed. Enhancements, improvements and new features: a good starting point is the user list, (IRC?) and possibly the dev list. If there is consensus, this should be filed at ??? <enhancements.koha-community.org> (similar to bugzilla) Best -- Paul [1] loosely based on Apache 2002.

2 1

Proposed "metadata" table for Koha
by David Cook 09 Dec '15

09 Dec '15

Hi all: For those not following along at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662, weve recently started talking about the possibility of adding a metadata table to Koha. The basic schema I have in mind would be something like: metadata.id, metadata.record_id, metadata.scheme, metadata.qualifier, metadata.value. The row would look like: 1, 1, marc21, 001, 123456789 It might also be necessary to store metadata.record_type so as to know where metadata.record_id points. This obviously has a lot of disadvantages redundant data between metadata rows, no database cascades via foreign keys, etc. However, it might be necessary in the short-term as a temporary measure. Of course, adding yet another place to store metadata might not seem like a great idea. We already store metadata in biblioitems.marcxml (and biblioitems.marc), Zebra, and other biblio/biblioitems/items relational database fields. Do we really need a new place to worry about data? That said, if were ever going to move away from MARC as the internal metadata format, we need to start transitioning to something new. Ive noticed this metadata table model in DSpace and other library systems, and it seems to work reasonable well. I dont know if wed break down the whole record into this structure, or if wed just break down certain fields as defined by a configuration file. In the short term, Id like to use something like this to access a records 001 without going to Zebra, which can be slow to update. I need to be able to query a record using the 001 as soon as its added to the database, and I cant necessarily get that from Zebra. I also need to be able to query a record, even if Zebra is down. Failing the metadata table idea, Im not sure how else wed expose the 001 and any number of other fields without using Zebra. We store the 020 and 022 in biblioitems.isbn and biblioitems.issn, but were putting multiple values in a single field, and thats not so great for searching. We might also want to add the 035 to the fields were searching, so I dont think just adding to the biblio or biblioitems tables will really do especially since were trying to move away from MARC. Anyway, please let me know your thoughts. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

3 7

Zebra, Query Parsing, Search, All the things
by David Cook 08 Dec '15

08 Dec '15

Hi all: I was getting 0 results when I should've been getting 78 results with the following query: Host-item:Criminology and criminal justice : an international journal I looked in the Zebra logs, and noticed that it was being transformed into the following: @not @and @attr 1=1033 Criminology @and @and @and @and @and criminal justice = an international journal @attr 1=9011 1 If we decompose the RPN, we'll see that it's basically saying: (Host-item=Crimology and ((((criminal and justice) and = ) and international) and journal )) not Suppression=1 The problem is that "=" is going to return 0 results, so the "and" will always be 0. The way to remedy this problem is to add quotes around our Host-item "value": Host-item:"Criminology and criminal justice an international journal" This will produce the following RPN query, which returns 78 results: @not @attr 1=1033 "Criminology and criminal justice = an international journal" @attr 1=9011 1 As far as I can tell, the = symbol is ignored. You can remove it or substitute another symbol and it'll still return the same number of results. Although it looks like using * for truncation doesn't work in double quotation marks... I suppose that's because it's already part of a term so you can't really translate it into RPN separately. I notice sometimes we strip out double quotation marks from queries and sometimes we add them in. we should probably do something consistent. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

2 1

Start of new release. Some updates.
by Brendan Gallagher 04 Dec '15

04 Dec '15

Now that the release is out, I wanted to give a quick little update for the following release. I will be traveling out of the country from December 1st till December 10th. Really what my plan is that the first few weeks we will not really be pushing new features. We want to concentrate on any bugs that are needed for 3.22.x and master. Kyle will be in the office and handling those needs. He will push and work on those bugs for us. Once I am back and settled in I will concentrate on bugs and new features. I am very open for discussion and I would like to talk with as many of you as I can about the great work that you're doing. Perhaps I will get a chance to speak with each of you about your plans development wise the next few months - so we can have a clear path on timing, getting you help testing your developments, and of course working with the whole team to help QA code. I think as long as we keep our expectations on the same page, we'll have a lot of success helping you meet the goals of a great stable release. Anything that we can do to help promote more initial sign-offs (probably our biggest bottleneck) the better. Let's see what things we can implement to encourage more of us testing the code. I will be encouraging our partner libraries and our staff to be doing as much as we can even with our busy schedules. Be proud! I plan on doing a weekly release newsletter. Thanks and as always don't hesitate to ask some questions. Brendan A. Gallagher

3 2

Release notes
by Frédéric Demians 04 Dec '15

04 Dec '15

Release notes for Koha new versions and maintenance versions are build automatically based on Git repository commits and Bugzilla info. A script named get_bugs.pl from release tools do the job. In the release notes, 4 info from BZ are used: - bug id - summary -- short description of the bug - component: equivalent of Koha module (Acquisition, Web Service, etc.) - severity: critic, normal, new feature, etc. A fifth info can be retrieved in order to describe in detail the bug/feature. This is just the first BZ comment. The first comment can't be changed later in BZ. So very often the 1st comment doesn't describe properly the bug. In order to improve the readability and usefulness of release notes, couldn't we: - Try to normalize and improve the bug summary field when the patch is pushed to master - Add an optional BZ custom field named releasenotes for example, which would contains useful info describing the bug in detail when necessary.

6 6