[Dbix-class] Maybe a Regression? Without a primary key, prefetches fail.

[Peter Rabbitson]

J. Shirley wrote:
> I'm not sure if this counts as a regression, but it was for me :)
> 
> I have a class which is defined as:
> 
> package MyApp::Schema::StupidJoinTable;
> 
> use strict;
> use warnings;
> 
> use base 'DBIx::Class';
> 
> __PACKAGE__->load_components("Core");
> 
> __PACKAGE__->table("stupid_join_table");
> __PACKAGE__->add_columns(
>     "stupid_id",
>     {
>         data_type       => "integer",
>         default_value   => undef,
>         is_nullable     => 0,
>         size            => 11
>     },
>     "stupider_id",
>     {
>         data_type       => "integer",
>         default_value   => undef,
>         is_nullable     => 0,
>         size            => 11
>     },
> );
> 
> __PACKAGE__->belongs_to( 'thing_1', 'MyApp::Schema::Thing', 'stupid_id');
> __PACKAGE__->belongs_to( 'thing_2', 'MyApp::Schema::Thing2', 'stupider_id');
> 
> 1;
> 
> 
> Now, if I attempt to prefetch this relationship, I get this error
> thrown (from DBIx/Class/Row.pm, line 1138):
>       $class->throw_exception("Implicit prefetch (via select/columns)
> not supported with accessor 'multi'");
> 
> The reason is that without ->set_primary_key(...) in this result
> definition, the query on type is an empty array.
> 
> So, $prefetch->{$pre} is simply an empty array (the line "if (ref
> $prefetch->{$pre}[0] eq 'ARRAY')").
> 
> 
> This behavior is not changed if I explicitly define the columns on the
> relationships (eg., { 'foreign.stupid_id' => 'self.stupid_id' })
> 
> I'm still running 0.08115 in production, so it is working there, but
> this came up on my tests as a failure.  The fix for me is just adding
> in the primary keys as they should be, but it seemed like an odd
> behavior.
> 
> If it's a bug, I'm happy to at least commit a failing test case :)
> 

It is a bug that became unmasked. If you use HRI to dump the prefetch
pre-115, you will see that from that point on data is silently dropped.
I.e. even if your database returned rows past the no-pk table, DBIC
will not consider them at all. The only thing the new code did was
*expect* to have data where it doesn't find any. I'll try to push
a patched up version by ened of this week, but the real fix (which does
not care about PKs at all) should appear mid April or earlier (ETOOBUSY)

Cheers