<!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 13126 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 5<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. Re: Dev meeting 5 January 2022 report (Katrin Fischer)<br> 2. New class: Koha::Result::Boolean (Tomas Cohen Arazi)<br> 3. Resultsets vs. list context (Tomas Cohen Arazi)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 6 Jan 2022 14:35:35 +0100<br>From: Katrin Fischer <katrin.fischer.83@web.de><br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Dev meeting 5 January 2022 report<br>Message-ID: <f635223e-6511-015c-b119-732bb94dc7a8@web.de><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Hi Jason,<br><br>if you haven't received a reply yet from the list admin, you can<br>unsubscribe yourself using the last option on this form:<br><br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br><br>Hope this helps,<br><br>Katrin<br><br>On 06.01.22 02:26, Jason Poulin wrote:<br>> Hi can someone take me off this list please I don’t know how I got on it thank you<br>><br>>> On Jan 5, 2022, at 5:57 PM, Fridolin SOMERS <fridolin.somers@biblibre.com> wrote:<br>>><br>>> Hi,<br>>><br>>> Here is Dev meeting 5 January 2022 report :<br>>> https://wiki.koha-community.org/wiki/Development_IRC_meeting_5_January_2022<br>>><br>>> Next dev meeting :<br>>> https://wiki.koha-community.org/wiki/Development_IRC_meeting_19_January_2022<br>>><br>>> There is also a general meeting soon :<br>>> https://wiki.koha-community.org/wiki/General_IRC_meeting_12_January_2022<br>>><br>>> See you around :D<br>>><br>>> Best regards,<br>>><br>>> --<br>>> Fridolin SOMERS <fridolin.somers@biblibre.com><br>>> Software and system maintainer 🦄<br>>> BibLibre, France<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>> 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>Message: 2<br>Date: Thu, 6 Jan 2022 12:19:45 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] New class: Koha::Result::Boolean<br>Message-ID:<br> <CABZfb=UM2_eZ9TPSSqooTS+=23Fxd1=MNDa3TPOQ-_aKuqRJ4Q@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi all, happy 2022 :-D<br><br>I wanted to mention that a bug that introduces Koha::Result::Boolean has<br>been pushed [1]. This class provides a way to return an object, that<br>evaluates to a boolean in (Perl's) bool context but also carries reasons<br>for the result.<br><br>It has been used in a couple places, like bug 29765 [2] and bug 29788 [3]<br>(which still needs the QA step).<br><br>[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29746<br>[2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29765<br>[3] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29788<br><br>-- <br>Tomás Cohen Arazi<br>Theke Solutions (http://theke.io)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220106/6e69ad0a/attachment-0001.htm><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 6 Jan 2022 13:21:21 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Resultsets vs. list context<br>Message-ID:<br> <CABZfb=VB142HzGNmLGUZxOmkOG7NQRqFza_hnZG9dfR3J6-zcA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi, let me tell you a short and (technical but) interesting story. Most of<br>you might know about this, but I found it could be useful to know and/or to<br>refresh.<br><br>DBIC has a nice property that our Koha::Objects inherited (obviously): you<br>can chain calls like this:<br><br> Koha::Patrons->search( $filter_1 )->search( $filter_2 )->search(<br>$filter_3 )->...;<br><br>We recently agreed (not sure there is a coding guideline) that if we wanted<br>to provide high-level methods to encapsulate such filters, we would call<br>those methods 'filter_by_*' unless the context suggests a better name. So<br>we could, in theory do something like:<br><br> my $cool_old_books = Koha::Biblios->search( $some_initial_filter )<br><br> ->filter_by_older_than({ years => 30 })<br><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.<br>This method allows us to, given a DBIC relationship, convert the linked<br>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,<br>they honor list context. This is:<br><br> my $scalar = Koha::Patrons->search(filter);<br> my @list = Koha::Patrons->search($filter);<br><br>will do what you think: $scalar will be an object, representing a<br>resultset, and @list will be the actually fetched list of results from the<br>search, as a list.<br><br>But there's a catch. And we need to be aware of that and there is an<br>ongoing discussion about it: _new_from_dbic doesn't honor list context [1].<br>This means when you code, you need to go look if the method you're calling<br>is _new_from_dbic-based, or ->search based [2]. This is not cool.<br><br> @checkouts = $patron->checkouts; # doesn't do what you expect!<br> @checkouts = $patron->checkouts->filter_by_overdue; # this does if<br>->search based.<br><br>Our codebase is full of places in which we either call ->as_list in our<br>resultsets (because something exploded if we didn't, for example):<br><br> my @checkouts = $patron->checkouts->as_list;<br><br>or in which we explicitly call `scalar the_thing' so we are sure things<br>are evaluated in scalar context because we want the resultset instead (for<br>example, when passing params to a template):<br><br> $template->param( checkouts => scalar $patron->checkouts );<br><br>I proposed we make ->_new_from_dbic and ->empty honor list context and<br>hence making our methods consistent (can be seen by the referenced bugs).<br>But we found a nasty problem: calling methods in Template::Toolkit<br>internally assigns them to a global stash which is implemented as a hash<br>(a.k.a. list context :-D). So, you will find that 'some' things are<br>calculated on the controller (.pl) scripts and then passed to the templates<br>(to overcome this), and some others are calculated directly in the<br>templates. Now you know the reason we've introduced those things over the<br>years in the codebase.<br><br>So, making _new_from_dbic honor list context, opens a big can of worms in<br>the template front. We explored the idea of using a different<br>Template::Toolkit stash, that honors scalar context, but the author has<br>marked it as experimental, and it would still require changing many things<br>in the templates. The tradeoff doesn't lean towards that path.<br><br>The conclusion so far is that we should drop support for list context.<br>Hence, my suggestion as developer and QA team member is:<br><br>TL;DR<br><br>Make use of ->as_list when you have a resultset really need list context<br>like in:<br><br>foreach my $item ( @{$items->as_list} ) { ... }<br>grep { filter($_) } @{@libraries->as_list}<br>my @biblios = $biblios->as_list;<br><br>and so on. This will save you some headaches (in some cases) and will make<br>your code survive this upcoming change. We should start enforcing this in<br>the QA step as well, so adjust your code for this. Once we remove<br>wantarray, things will explode on their own.<br><br>Best regards<br><br>[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28883<br>[2] There is also Koha::Objects->empty, actually. That presents the same<br>problem as _new_from_dbic.<br>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28871<br><br>--<br>Tomás Cohen Arazi<br>Theke Solutions (http://theke.io)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220106/5d5a5dd6/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 5<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>