[Dbix-class] Re: Join behavior in "prefetch" vs "join"
Nilson Santos Figueiredo Junior
acid06 at gmail.com
Fri Jan 9 19:44:44 GMT 2009
On Fri, Jan 9, 2009 at 3:09 PM, Nilson Santos Figueiredo Junior
<acid06 at gmail.com> wrote:
> So - is prefetch really expected to work like that?
> I can explain better if this message isn't clear enough and a test
> case if it seems to be a bug.
Just an update, with some quick code snippets which might be able to
better explain the issue.
These are the relationship definitions:
package My::Schema::Foo;
__PACKAGE__->has_many( 'bars', 'My::Schema::Bar', { 'foreign.foo_id'
=> 'self.id' } );
package My::Schema::Bar;
__PACKAGE__->has_many('quuxes', 'My::Schema::Quux', {
'foreign.bar_id' => 'self.id' } );
package My::Schema::Quux;
__PACKAGE__->belongs_to('parent', 'My::Schema::Parent', { id =>
'parent_id' } );
Then, some sample queries:
my $prefetch_rs = $schema->resultset('Foo')->search( undef, {
prefetch => { bars => { quuxes => 'parent' } }
} );
my $join_rs = $schema->resultset('Foo')->search( undef, {
join => { bars => { quuxes => 'parent' } }
} );
In this case, $prefetch_rs will emit something like:
LEFT JOIN bar LEFT JOIN quux JOIN parent
While $join_rs will emit something like:
LEFT JOIN bar LEFT JOIN quux LEFT JOIN parent
The expected behavior is better matched by the query emitted by
$join_rs (an exact match would be using nested joins, so that quux
still must have a parent, but that wouldn't exclude the entire 'bar'
row from the resultset).
So, I hope this explains it better.
-Nilson Santos F. Jr.
More information about the DBIx-Class
mailing list