DBIx::Class has a compile-time interface. The approach that comes to mind is a perl-perl wrapper main that generates the variable compile-time code at run-time and then calls the static code also by require that in turn requires the variable compile-time code. For example:

Actual main program (outer wrapper):

#!/usr/bin/perl

use strict;

use warnings;

print "enter some perl code: ";

open my $r2h, '>require2.pl';
my $code = <>;
print $r2h $code;

close $r2h;

require 'require1.pl';
[download]

intended main program is require1.pl which can now load the variable code in require2.pl also by the require statement. Functionally main program require1.pl does not get compiled until require2.pl has been generated at run-time by the above artificial actual main program (wrapper).

update: for multithreaded use, require1.pl has to be spawned rather than required and with e.g. a table name parameter and require2.pl will instead have a filename derived from the table name.

It's all awkward, so you may also want to ask yourself if you really want to make a compile-time class behave outside its remit rather than choosing an alternative run-time-oriented DBI class.

more update: correction: require1.pl should "use" not require the variable code require2.pl (now a misnomer) so that it is loaded at the compile time of require1.pl instead of its run-time.