[Koha-bugs] [Bug 19809] Koha::Objects::find calls do not need to be forbidden in list context

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19809

--- Comment #17 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to Marcel de Rooy from comment #15)
> Yes, this is very theoretical.
> You strip the @pars array now. Before we passed the original array unless it
> only consisted of undefined values.
> So suppose I pass 51, undef, 13. You are now passing 51, 13. Different thing!
> Note that find responds to multiple column PKs and unique constraint stuff.
> (We are probably not using in Koha.)

Ah yes, you are right. Even if we are not using it in Koha it may be used by
external tools or plugins, so it needs to be fixed

(In reply to Marcel de Rooy from comment #16)
> OK. I didnt get that right away. It is quite unperlish to return ( undef ).
> But yes, I checked and DBIx does it here..
> So, should we stick to perl or to DBIx ? Since Koha::Objects relies on DBIx,
> I wouldnt mind doing the latter here.

I don't know if it's perlish or not. To me it just feels natural to always get
a value (even if that value is undef) when I call find. And when you think
about it, that's what we get actually by being forced to put scalar in front of
`find` calls.

Also, it's not that uncommon in other Perl modules. Cache::Memcached does the
same thing for instance

% perl -MCache::Memcached -MData::Dumper -E '$memd = new Cache::Memcached; say
Dumper [$memd->get("mykey")];'

$VAR1 = [
          undef
        ];

It would be great to have Jonathan's opinion as he wrote the patch for bug
18539

-- 
You are receiving this mail because:
You are watching all bug changes.