[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