[Dbix-class] DBD::Multiplex - do NOT use

[Rob Kinyon]

On 9/8/06, Tim Bunce <Tim.Bunce at pobox.com> wrote:
> > #3 is the biggest issue - $dbh's and $sth's are treated identically
> > when they cannot be.
>
> In the typical use-cases for DBD::Multiplex the $dbh would have multiple
> underlying handles, but the prepare would return an $sth that only had one.
> The prepare() picks which underlying dbh(s) should be used, and typically
> it's just one - the multiplexing code isn't relevant in that situation.

That's part of the problem - DBD::Multiplex attempts to address
several use cases:
    * high availability / failover
    * master-write/slave-read
    * situations where different DBs might give different answers

It does none of those well (except, strangely, for the last).

> Unless there's a very good reason not to I'd suggest that DBIx::Class
> add the concept of a read-only db connection that defaults to the main
> db connection. Then use that read-only db connection for all read-only
> db actions.

I agree with Tim completely. The lowest level that can really
determine what's best is the ORM. For one thing, how do you determine
at the SQL level if a statement is meant to mutate? It's not trivial.

Rob