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

Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find calls in list context
by Julian Maurice 15 Dec '17

15 Dec '17

Probably, but that's not my point. I understand why the previous code needed to be fixed, which is to avoid that { a => Koha::Patrons->find("foo"), b => "bar" } would result in { a => "b", "bar" => undef } My question is: why the solution to this problem was to forbid calls in list context while we could simply return an explicit undef? It forces us to write 'scalar' in front of a call that should always return a single value, and in my opinion it's a "code smell" Le 13/12/2017 à 15:29, Marcel de Rooy a écrit : > i forgot to add scalar in the second.. > > probably you should > > if( $a = xxx->find ) > > push @b, $a > > > ------------------------------------------------------------------------ > *Van:* Julian Maurice <julian.maurice(a)biblibre.com> > *Verzonden:* woensdag 13 december 2017 15:20:34 > *Aan:* Marcel de Rooy > *Onderwerp:* Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find > calls in list context > > This particular line will work (only the first, in the second, find is > still called in list context), but @a would contain one element (undef) > and the example code given by Jonathan will also fail, whether we call > find in list context or not. > > Le 13/12/2017 à 15:12, Marcel de Rooy a écrit : >> Are you sure ? >> >> push @a, scalar Koha..->find >> >> or @a = ( ...->find ) >> >> >> should work imo >> >> ------------------------------------------------------------------------ >> *Van:* koha-devel-bounces(a)lists.koha-community.org >> <koha-devel-bounces(a)lists.koha-community.org> namens Julian Maurice >> <julian.maurice(a)biblibre.com> >> *Verzonden:* woensdag 13 december 2017 15:07:11 >> *Aan:* Jonathan Druart >> *CC:* koha-devel(a)lists.koha-community.org >> *Onderwerp:* Re: [Koha-devel] Bug 18539 - Forbid Koha::Objects->find >> calls in list context >> >> Ok, but the proposed fix doesn't fix this code: >> >> @a = scalar Koha::Patrons->find('foo'); >> if (@a) { # still equals to 1 >> say $a[0]->borrowernumber; # still BOOM >> } >> >> And yes, that was the link ;) >> >> Le 13/12/2017 à 14:58, Jonathan Druart a écrit : >>> Hi Julian, >>> >>> >>>> @a = Koha::Patrons->find('foo'); # would result in @a = (undef) >>> >>> And that leads to issues: >>> if ( @a ) { # = 1 >>> say $a[0]->borrowernumber; # BOOM >>> } >>> >>> See also https://perlmaven.com/how-to-return-undef-from-a-function (was >>> it the link you were talking about?) >>> >>> Cheers, >>> Jonathan >>> >>> On Wed, 13 Dec 2017 at 10:34 Julian Maurice <julian.maurice(a)biblibre.com >>> <mailto:julian.maurice@biblibre.com>> wrote: >>> >>> Hi developers, >>> >>> I stumbled upon a line of code recently and I can't figure out why it >>> has be done this way. I hope you can help me :) >>> >>> The line in question is in Koha::Objects::find: >>> >>> croak 'Cannot use "->find" in list context' if wantarray; >>> >>> I read the two bugs (18539 and 18179) and the link given by Jonathan but >>> I still don't understand why the call in list context has been >>> forbidden. Why not simply return undef (an explicit undef) when no >>> records have be found ? It would work as expected in scalar and list >>> contexts. >>> >>> Here is a possible rewrite of 'find' to better explain what I mean: >>> >>> sub find { >>> my ( $self, @pars ) = @_; >>> >>> my $object = undef; >>> >>> @pars = grep { defined } @pars; >>> if (@pars) { >>> my $result = $self->_resultset()->find(@pars); >>> if ($result) { >>> $object = >>> $self->object_class()->_new_from_dbic($result); >>> } >>> } >>> >>> return $object; >>> } >>> >>> @a = Koha::Patrons->find('foo'); # would result in @a = (undef) >>> {a => K::P->find('foo'), b => 'bar'}; # would result in {a => undef, b >>> => 'bar'} >>> >>> Please tell me what you think. >>> >>> -- >>> Julian Maurice <julian.maurice(a)biblibre.com >>> <mailto:julian.maurice@biblibre.com>> >>> BibLibre >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel(a)lists.koha-community.org >>> <mailto:Koha-devel@lists.koha-community.org> >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> >> -- >> Julian Maurice <julian.maurice(a)biblibre.com> >> BibLibre >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel(a)lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > -- > Julian Maurice <julian.maurice(a)biblibre.com> > BibLibre -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

3 4

Reminder string freeze for stable December 15th
by Nick Clemens 14 Dec '17

14 Dec '17

Hi All, I mentioned at the meetings yesterday but just sending a reminder not here. Pushing patches today and catching up now, string freeze tomorrow. -Nick (kidclamp)

1 0

Call for News: December 2017 Newsletter
by kohanews 14 Dec '17

14 Dec '17

I'm collecting news for the December newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Add a digest option for AUTO_RENEWALS Notice
by Owen Leonard 13 Dec '17

13 Dec '17

Is anyone currently working on, or have plans to work on Bug 19736, "Add a digest option for AUTO_RENEWALS Notice?" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19736 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Bug 18539 - Forbid Koha::Objects->find calls in list context
by Julian Maurice 13 Dec '17

13 Dec '17

Hi developers, I stumbled upon a line of code recently and I can't figure out why it has be done this way. I hope you can help me :) The line in question is in Koha::Objects::find: croak 'Cannot use "->find" in list context' if wantarray; I read the two bugs (18539 and 18179) and the link given by Jonathan but I still don't understand why the call in list context has been forbidden. Why not simply return undef (an explicit undef) when no records have be found ? It would work as expected in scalar and list contexts. Here is a possible rewrite of 'find' to better explain what I mean: sub find { my ( $self, @pars ) = @_; my $object = undef; @pars = grep { defined } @pars; if (@pars) { my $result = $self->_resultset()->find(@pars); if ($result) { $object = $self->object_class()->_new_from_dbic($result); } } return $object; } @a = Koha::Patrons->find('foo'); # would result in @a = (undef) {a => K::P->find('foo'), b => 'bar'}; # would result in {a => undef, b => 'bar'} Please tell me what you think. -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

3 4

Bug 19767: serial-issues.pl unused?
by Owen Leonard 12 Dec '17

12 Dec '17

Bug 19767 - serial-issues.pl is unused and should be removed https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19767 I think serial-issues.pl, serial-issues.tt, and serial-issues-full.tt are obsolete and should be removed. Does anyone know of any reason not to? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

5 5

SIG DIE in returns.pl
by Fridolin SOMERS 12 Dec '17

12 Dec '17

Hie, With plack when some code fails, there is always in log a reference to circ/returns.pl o_O at start of stack trace. I found that there is in this page : use Carp 'verbose'; $SIG{ __DIE__ } = sub { Carp::confess( @_ ) }; Added by commit bb6277ffcc593685554112d770ac273c9efeda33 Bug 14464: Add ability to cancel waiting holds from checkin screen Is this for debug purpopse only ? Why only this page ? Should it be moved to plack.psgi ? Regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre - software and system maintainer

6 6

error with Z39.50
by Johan Seyfferdt 11 Dec '17

11 Dec '17

Hello, sorry for asking another question We ran into another error this time with z39.50. We added several servers but when trying to use this service we get the following error. Unsupported UNIMARC character encoding [] for XML output for UNIMARC; 100$a -> at /usr/share/perl5/MARC/File/XML.pm line 568. For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error. Any help will be greatly appreciated! Johan

2 1

Koha 17.11.00 package / repository rollover
by Mirko Tietgen 11 Dec '17

11 Dec '17

Good news everyone, the Debian package for Koha 17.11.00 is now available from the community repository. With the new major release, the repository structure will change slightly. Koha 17.11 is now 'stable'. Koha 17.05 is now 'oldstable' Koha 16.11 is still maintained, but no futher Debian packages are provided. The last packaged version 16.11.14 is available from the 16.11 pocket of the repository. Koha 16.05 has had its last release two weeks ago and is no longer maintained. The final version 16.05.19 is now available from the 16.05 pocket of the repository. Please check the wiki for detailed apt configuration information: https://wiki.koha-community.org/wiki/Koha_on_Debian#Set_up_package_sources Have a nice weekend, Mirko

4 3

Patrons endpoint help needed
by Tomas Cohen Arazi 08 Dec '17

08 Dec '17

Hi everyone, I've submitted a patchset to bug 19784 [1]. This is my starting point for the umbrella bug (19774). Next endpoints to fix are /acquisitions/vendors, /cities, /holds and /illrequests. Those are easier IMHO. On the /patrons one, I already changed - borrowernumber -> patron_id - branchcode -> library_id - categorycode -> category_id The needed code for this (or any) attribute rename is already done. The remaining work is mostly adding the mappings we would like to add, to the _to_model and _to_api functions. I now need help from you on the parameter names (patrons have really misleading attribute names, and they don't match the UI most of the time). Please comment here, and preferably on the bug itself. If you contribute a patch for your proposed change, please add a test on the specific attribute on one of the GET tests too. We try to cover all the special cases with tests. Ah, snake case was picked at some point, so 'cardnumber' could become 'card_number', for example. Thanks for any input. [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19784 -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

1 1