Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Re: Dev meeting 5 January 2022 report (Katrin Fischer)
2. New class: Koha::Result::Boolean (Tomas Cohen Arazi)
3. Resultsets vs. list context (Tomas Cohen Arazi)


----------------------------------------------------------------------

Message: 1
Date: Thu, 6 Jan 2022 14:35:35 +0100
From: Katrin Fischer <katrin.fischer.83@web.de>
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Dev meeting 5 January 2022 report
Message-ID: <f635223e-6511-015c-b119-732bb94dc7a8@web.de>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Jason,

if you haven't received a reply yet from the list admin, you can
unsubscribe yourself using the last option on this form:

https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

Hope this helps,

Katrin

On 06.01.22 02:26, Jason Poulin wrote:
> Hi can someone take me off this list please I don’t know how I got on it thank you
>
>> On Jan 5, 2022, at 5:57 PM, Fridolin SOMERS <fridolin.somers@biblibre.com> wrote:
>>
>> Hi,
>>
>> Here is Dev meeting 5 January 2022 report :
>> https://wiki.koha-community.org/wiki/Development_IRC_meeting_5_January_2022
>>
>> Next dev meeting :
>> https://wiki.koha-community.org/wiki/Development_IRC_meeting_19_January_2022
>>
>> There is also a general meeting soon :
>> https://wiki.koha-community.org/wiki/General_IRC_meeting_12_January_2022
>>
>> See you around :D
>>
>> Best regards,
>>
>> --
>> Fridolin SOMERS <fridolin.somers@biblibre.com>
>> Software and system maintainer 🦄
>> BibLibre, France
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : https://www.koha-community.org/
>> git : https://git.koha-community.org/
>> bugs : https://bugs.koha-community.org/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/


------------------------------

Message: 2
Date: Thu, 6 Jan 2022 12:19:45 -0300
From: Tomas Cohen Arazi <tomascohen@gmail.com>
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] New class: Koha::Result::Boolean
Message-ID:
    <CABZfb=UM2_eZ9TPSSqooTS+=23Fxd1=MNDa3TPOQ-_aKuqRJ4Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all, happy 2022 :-D

I wanted to mention that a bug that introduces Koha::Result::Boolean has
been pushed [1]. This class provides a way to return an object, that
evaluates to a boolean in (Perl's) bool context but also carries reasons
for the result.

It has been used in a couple places, like bug 29765 [2] and bug 29788 [3]
(which still needs the QA step).

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29746
[2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29765
[3] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29788

--
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220106/6e69ad0a/attachment-0001.htm>

------------------------------

Message: 3
Date: Thu, 6 Jan 2022 13:21:21 -0300
From: Tomas Cohen Arazi <tomascohen@gmail.com>
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: [Koha-devel] Resultsets vs. list context
Message-ID:
    <CABZfb=VB142HzGNmLGUZxOmkOG7NQRqFza_hnZG9dfR3J6-zcA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.

DBIC has a nice property that our Koha::Objects inherited (obviously): you
can chain calls like this:

Koha::Patrons->search( $filter_1 )->search( $filter_2 )->search(
$filter_3 )->...;

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:

my $cool_old_books = Koha::Biblios->search( $some_initial_filter )

->filter_by_older_than({ years => 30 })

->filter_by_coolness();

So far, so good :-D

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:

my $patron_checkouts = $patron->checkouts;

in this case, the actual code is pretty simple thanks to _new_from_dbic:

sub checkouts {
my ($self) = @_;
my $checkouts = $self->_result->issues;
return Koha::Checkouts->_new_from_dbic( $checkouts );
}

Methods like ->search behave consistently to what DBIC does, and as such,
they honor list context. This is:

my $scalar = Koha::Patrons->search(filter);
my @list = Koha::Patrons->search($filter);

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.

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.

@checkouts = $patron->checkouts; # doesn't do what you expect!
@checkouts = $patron->checkouts->filter_by_overdue; # this does if
->search based.

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):

my @checkouts = $patron->checkouts->as_list;

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):

$template->param( checkouts => scalar $patron->checkouts );

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.

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.

The conclusion so far is that we should drop support for list context.
Hence, my suggestion as developer and QA team member is:

TL;DR

Make use of ->as_list when you have a resultset really need list context
like in:

foreach my $item ( @{$items->as_list} ) { ... }
grep { filter($_) } @{@libraries->as_list}
my @biblios = $biblios->as_list;

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.

Best regards

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28883
[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

--
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220106/5d5a5dd6/attachment-0001.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/


------------------------------

End of Koha-devel Digest, Vol 194, Issue 5
******************************************