<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 13157 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 194, Issue 7<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Listing as a Koha Support provider - https://koha-support.eu/<br> (Mark Hofstetter)<br> 2. Re: Resultsets vs. list context (dcook@prosentient.com.au)<br> 3. Reusable barcode? (Waylon Robertson)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 9 Jan 2022 17:14:40 +0100<br>From: Mark Hofstetter <mark@hofstetter.at><br>To: koha-devel@lists.koha-community.org<br>Subject: [Koha-devel] Listing as a Koha Support provider -<br> https://koha-support.eu/<br>Message-ID: <119cd511-ddcd-d58f-d7fb-932b6c34d155@hofstetter.at><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Hi,<br><br>we are the HKS3 (Hofstetter, Klausner & Schmidt) OG and started <br>providing support for koha about 1,5 years ago - and would like to be <br>listed as "Koha Support provider"<br><br> Company Name: HKS3<br><br> Contact Person: Mark Hofstetter<br><br> Contact email: office@koha-support.eu<br><br> Website: https://koha-support.eu/<br><br> Telephone: +43 676 7345660<br><br>this week our biggest project so far went live this weekend at:<br><br>https://katalog.landesbibliothek.steiermark.at/<br><br>( around 600k records)<br><br>we are long time perl and database developers and want to (and already <br>did) participate in the great & very welcoming koha-community<br><br>some (and future) contributions<br><br>https://github.com/HKS3/<br><br>cheers & thanks<br><br>Mark<br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 10 Jan 2022 12:32:05 +1100<br>From: <dcook@prosentient.com.au><br>To: "'Tomas Cohen Arazi'" <tomascohen@gmail.com>, "'koha-devel'"<br> <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Resultsets vs. list context<br>Message-ID: <018501d805c1$e07683c0$a1638b40$@prosentient.com.au><br>Content-Type: text/plain; charset="utf-8"<br><br>That was really interesting. Sounds like a good call to me. I’ve never really been a fan of ‘wantarray’ black magic anyway. <br><br> <br><br>David Cook<br><br>Senior Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Tomas Cohen Arazi<br>Sent: Friday, 7 January 2022 3:21 AM<br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Resultsets vs. list context<br><br> <br><br>Hi, let me tell you a short and (technical but) interesting story. Most of you might know about this, but I found it could be useful to know and/or to refresh.<br><br> <br><br>DBIC has a nice property that our Koha::Objects inherited (obviously): you can chain calls like this:<br><br> Koha::Patrons->search( $filter_1 )->search( $filter_2 )->search( $filter_3 )->...;<br><br>We recently agreed (not sure there is a coding guideline) that if we wanted to provide high-level methods to encapsulate such filters, we would call those methods 'filter_by_*' unless the context suggests a better name. So we could, in theory do something like:<br><br> my $cool_old_books = Koha::Biblios->search( $some_initial_filter )<br> ->filter_by_older_than({ years => 30 })<br> ->filter_by_coolness();<br><br>So far, so good :-D<br><br>But then, we have another (cool) method in Koha::Objects: _new_from_dbic. This method allows us to, given a DBIC relationship, convert the linked resultset into the proper Koha::Object(s)-based class. For example:<br><br> my $patron_checkouts = $patron->checkouts;<br><br>in this case, the actual code is pretty simple thanks to _new_from_dbic:<br><br>sub checkouts {<br> my ($self) = @_;<br> my $checkouts = $self->_result->issues;<br> return Koha::Checkouts->_new_from_dbic( $checkouts );<br>}<br><br>Methods like ->search behave consistently to what DBIC does, and as such, they honor list context. This is:<br><br> <br><br> my $scalar = Koha::Patrons->search(filter);<br><br> my @list = Koha::Patrons->search($filter);<br><br> <br><br>will do what you think: $scalar will be an object, representing a resultset, and @list will be the actually fetched list of results from the search, as a list.<br><br>But there's a catch. And we need to be aware of that and there is an ongoing discussion about it: _new_from_dbic doesn't honor list context [1]. This means when you code, you need to go look if the method you're calling is _new_from_dbic-based, or ->search based [2]. This is not cool.<br><br> <br><br> @checkouts = $patron->checkouts; # doesn't do what you expect!<br><br> @checkouts = $patron->checkouts->filter_by_overdue; # this does if ->search based.<br><br> <br><br>Our codebase is full of places in which we either call ->as_list in our resultsets (because something exploded if we didn't, for example):<br><br> <br><br> my @checkouts = $patron->checkouts->as_list;<br><br> <br><br>or in which we explicitly call `scalar the_thing' so we are sure things are evaluated in scalar context because we want the resultset instead (for example, when passing params to a template):<br><br> <br><br> $template->param( checkouts => scalar $patron->checkouts );<br><br> <br><br>I proposed we make ->_new_from_dbic and ->empty honor list context and hence making our methods consistent (can be seen by the referenced bugs). But we found a nasty problem: calling methods in Template::Toolkit internally assigns them to a global stash which is implemented as a hash (a.k.a. list context :-D). So, you will find that 'some' things are calculated on the controller (.pl) scripts and then passed to the templates (to overcome this), and some others are calculated directly in the templates. Now you know the reason we've introduced those things over the years in the codebase.<br><br> <br><br>So, making _new_from_dbic honor list context, opens a big can of worms in the template front. We explored the idea of using a different Template::Toolkit stash, that honors scalar context, but the author has marked it as experimental, and it would still require changing many things in the templates. The tradeoff doesn't lean towards that path.<br><br> <br><br>The conclusion so far is that we should drop support for list context. Hence, my suggestion as developer and QA team member is:<br><br> <br><br>TL;DR<br><br> <br><br>Make use of ->as_list when you have a resultset really need list context like in:<br><br> <br><br>foreach my $item ( @{$items->as_list} ) { ... }<br><br>grep { filter($_) } @{@libraries->as_list}<br><br>my @biblios = $biblios->as_list;<br><br> <br><br>and so on. This will save you some headaches (in some cases) and will make your code survive this upcoming change. We should start enforcing this in the QA step as well, so adjust your code for this. Once we remove wantarray, things will explode on their own.<br><br> <br><br>Best regards<br><br> <br><br>[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28883<br><br>[2] There is also Koha::Objects->empty, actually. That presents the same problem as _new_from_dbic. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28871<br><br> <br><br>--<br>Tomás Cohen Arazi<br>Theke Solutions (http://theke.io)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220110/b4cc5d4e/attachment-0001.htm><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 10 Jan 2022 08:13:22 +0000 (UTC)<br>From: Waylon Robertson <wrobertson1981@yahoo.co.nz><br>To: "koha-devel@lists.koha-community.org"<br> <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Reusable barcode?<br>Message-ID: <2119197562.871463.1641802402508@mail.yahoo.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Is there a way to use a barcode multiple times, as a category/tag on checkin/out? A toy library would like to just have categories like 'Game', 'vehicle', 'book', etc, and to scan those, instead of barcoding each item individually.<br>How would this work?<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220110/bbcffa85/attachment-0001.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 194, Issue 7<br>******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>