ag4ve has asked for the wisdom of the Perl Monks concerning the following question:

i've got three tables: grp_org which has_many grp_own which has_many groups

i'm trying to create a data stricture which should have the data in a reasonable form. i can do the join from grp_org to grp_own fine, but when i try to join to groups, i'm failing.

what i have / tried:

my $grporg_rs = $schema->resultset('GrpOrg'); my $thing = [ $grporg_rs->search_rs( { }, { result_class => 'DBIx::Class::Re +sultClass::HashRefInflator', select => [ qw/me.org grp_ +own.owner/ ], join => 'grp_own', } )->search_rs( { }, { select => [ qw/groups.name +/ ], join => 'groups' } )->all ]; </cod> <p>i've also tried to use ->search_related. my schema looks like: <code> GrpOrg.pm: __PACKAGE__->has_many( "grp_own", "Nais::Schema::Result::GrpOwn", { "foreign.org_id" => "self.id" }, { cascade_copy => 0, cascade_delete => 0 }, ); GrpOwn.pm: __PACKAGE__->has_many( "groups", "Nais::Schema::Result::Group", { "foreign.own_id" => "self.id" }, { cascade_copy => 0, cascade_delete => 0 }, ); __PACKAGE__->belongs_to( "grp_org", "Nais::Schema::Result::GrpOrg", { id => "org_id" }, { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" + }, ); Groups.pm: __PACKAGE__->has_many( "grp2ais", "Nais::Schema::Result::Grp2ai", { "foreign.gpk" => "self.gpk" }, { cascade_copy => 0, cascade_delete => 0 }, );

Replies are listed 'Best First'.
Re: dbic multiple joins
by moritz (Cardinal) on Apr 23, 2011 at 16:40 UTC

      ya know, i just don't get it. i read thought that whole doc today and just didn't see that. at any rate, i couldn't figure out how to use 'join =>' to do what i want, but 'prefetch => { grp_own => 'groups' }' works pretty decent.

      i can't figure out how to limit the records i'm returning, and if i use 'select' it seems to mess up my data structure. though, i haven't played with it for that long now, so maybe it's just a matter of ' try harder' :)

      thanks

Re: dbic multiple joins
by Anonymous Monk on Apr 25, 2011 at 14:50 UTC
    Since disk space is relatively cheap, maybe the best way to solve these "multi-level marketing" type problems is to construct a fully-exploded mapping, e.g. in a separate table. Presumably the memberships don't change that often, whereas lookups happen constantly and time is of the essence. Trade space for time. Do the work ahead of time so that you can always get the answer with one query.