https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19809
--- Comment #17 from Julian Maurice <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
