It works! Thanks very much!

I understand, now that you pointed it out (!), what I was doing wrong. The player_data_currs relationship is referring to a resultset because has_many relationships always refer to resultsets. So, although there is only a single record in $player_static->player_data_currs->all, I need to get the single object/record from the resultset and then call team_libl on it.

$player_static->player_data_currs->all->team_libl->id doesn't work either because, again, I am calling team_libl on a resultset not on a single object.

I see now that if I go the other way, from PlayerDataCurr to PlayerDataStatic through a belongs_to relation in PlayerDataCurr, I can accomplish what I'm after much more easily. I suppose this is because a belongs_to links to an object not a resultset. Is that right?

__PACKAGE__->belongs_to(
  "id_static",
  "LIBL::Schema::Result::PlayerDataStatic",
  { id => "id_static" },
  {
    is_deferrable => 1,
    join_type     => "LEFT",
    on_delete     => "CASCADE",
    on_update     => "CASCADE",
  },
);
[download]

my $roster_rs = $player_curr_model->search(
    {
        team_libl => { '!=' => undef },
    },
    {
        prefetch => [ 'id_static', ],
    },
);

foreach my $player_curr ( $roster_rs->all ) {
    say $player_curr->team_libl;
}
[download]

(I apparently have only a very fuzzy grasp of the difference in relationships. I have struggled over DBIx::Class::Relationship but never really understood it.)

Thanks again for your help. Your succinct explanation taught me something that I could not discover on my own.

Since you're being so nice! Here is something else you might try. Part of the power of DBIC is the chained ResultSet. Customizing them with semantically significant names (beware shortcut names) can let you build up an amazing set of chained stuff. For example–

package LIBL::Schema::ResultSet::PlayerDataCurr;
use strict;
use warnings;
use parent "DBIx::Class::ResultSet::HashRef"; # <-Nice alternative to 
+DBIx::Class::ResultSet.

sub teams {
    +shift->search({ team_libl => { '!=' => undef } });
}

sub teams_rs { scalar +shift->teams }

sub with_id_static {
    +shift->search({}, { prefetch => [ 'id_static' ] });
}

sub with_id_static_rs { scalar +shift->with_id_static }

1;

__END__

=pod

=head1 Do you even Pod?

L<JSON> + L<DBIx::Class::ResultSet::HashRef> for speedy delivery.

  use JSON;
  for my $team ( $player_curr_model->teams->hashref_rs->all )
  {
      print encode_json($team), $/;
  }

  # OR
  my @teams = $player_curr_model
                ->teams
                ->with_id_static;

=cut
[download]

So, that is pretty contrived (and again UNTESTED) with splitting the with_id_static out but I think you can see how to put it back into the other sub and mix and match and build up chained calls that keep it very semantic and easy to test, repurpose, and maintain. DBIx::Class::ResultSet::HashRef is a regular ResultSet class with shortcuts to avoid the penalty of inflating data to objects when you prefer.

Wow. I have seen references and examples of chaining resultsets in the docs, but none that seemed useful, so I have ignored them until now. Your example shows how to use them in a way that's relevant to what I am typically doing and how to code them.

I incorporated these searches into two of my Schema::Resultsets and greatly shortened and simplified my code. They provide a very short way to "move" back and forth between related records. Much better than what I have been using.

Pretty darn cool. Thanks again.