Right off you can be sure that you will never need $c. The Catalyst context is, well, SHOULD be, entirely irrelevant to all DB operations. If not, you may have a “broken design.”

The DB has its own proper routes to information and self-reference. It’s only being consumed by Catalyst, it is not intrinsically a part of it at all. Generally, no DBIC question is ever a Catalyst question and vice versa.

So, there are probably a few ways to do what you want, if I’m correctly guessing what you want; which is to create a club record, presumably from MyApp::Controller::Club->something with valid venue.

    my $club = $c->model("DB::Clubs")
        ->create({ some_data => "asdfasdf",
                   venue => $id });
[download]

If your data is InnoDB or equivalent with proper foreign keys this will throw an exception on a bad venue because your DB will not allow bad integrity to be stored. Then you just eval and recover in the controller, or do a general purpose version of same in you /end controller where $c->errors (all fatals) are available to be handled (and cleared) or passed along as a server error.

I take it you are trying to avoid things like the following. But there is nothing wrong with this approach so don’t avoid it out of some sense of purity. Maybe you don’t know about it. This one will also throw an error if the venue is bad whether or not your DB cares.

    my $venue = $c->model("DB::Venue")->find($id);
    $venue->add_to_clubs({ some_club_data => "Without venue" });
[download]

Now, the last possibility (well, the last obvious one) is that you have no DB integrity (your foreign keys are advisory, not enforced) and you don’t want to do any handling in Catalyst. In this case you might have to do something like this–

# Inside MySchema::Result::Club.
sub insert {
    my $self = shift;
    return $self if $self->in_storage;
    croak "No venue provided..." unless $self->venue;
    my $schema = $self->result_source->schema;
    croak "Venue is invalid..."
        unless $schema->resultset("Venue")->find($self->venue);
    $self->next::method();
}

sub update {
    my $self = shift;
    my %to_update = $self->get_dirty_columns
        || return $self->next::method(@_);
    $to_update{venue} || return $self->next::method(@_);
    croak "Venue is invalid..."
        unless $schema->resultset("Venue")->find($to_update{venue});
    $self->next::method(@_);
}
[download]

That’s rough but probably functional (none of this code was tested but I have used all of the approaches at some point). You can see why letting the DB handle integrity is saner policy. When you have to code around it, many edge cases pop up and get messy and can trash performance.