A public method for passing in userid/password for a connection.

[dmcbride]

Or, failing that, a public method for passing in a connection.

I understand that there is a .dbic.yaml that DBIx::Config uses for setting the connect parameters. However, that works fine only when the user is using that. The project I've inherited where I'd like to use App::DH has its own configuration file already, where the connect parameters are stored alongside dozens of other operational configuration parameters.

Asking App::DH to interpret that file is too much of an ask. However, allowing my App::DH derivation to perform that lookup and pass in the parameters would be a reasonable compromise, I would think.

What I've done for now is override _build__schema to build the connection, and this seems to work. However, it's an undocumented method, so this issue is asking for a documented method of creating the connection with a user-supplied id and password.

[kentfredric]

If I provided a default sub called "connection_args" , which by default returned an empty list, and was called as:

sub _build__schema {
  my ($self) = @_;
  require lib;
  lib->import($_) for @{ $self->include };
  require Module::Runtime;
  my $class = Module::Runtime::use_module( $self->schema );
  return $class->connect( $self->connection_name, $self->connection_args );
}

With the intent that you override it in a subclass,

Would that be suitable?

[dmcbride]

That sounds great. In theory someone could take that and make it more params if they wanted, but that's not what I'd be looking for.

I would refactor my existing framework to connect similarly so that one chunk of code pulls the connection args for both, I think that'd work great.

[kentfredric]

Actually, I'm not sure if that interface is the best long term. I'm conflicted.

There's another approach that could be taken:

sub connection_args { 
     my ( $name ) = @_;
     return ( $name, @extra_args );
}
...
    $class->connect( $self->connection_args( $self->connection_name ));

But this makes the average usecase harder in effort to make a more general usecase available.

[dmcbride]

I would almost suggest renaming _schema to connection and document it. The default _build_connection would do what _build__schema does today (i.e., just a rename), allowing others to see it as documented and override the builder or provide a default directly or whatever to end up with the connected object that App::DH can use.

This still allows, more or less, you to provide a smarter builder in the future that took extra arguments in some manner that should make this usecase easier without sacrificing the average usecase. Anyone who overrides your builder won't get those benefits, but also probably doesn't require them. Or, you never find a better way, and just leave it :)