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

[Tim Bunce]

On Fri, Sep 08, 2006 at 08:15:15PM -0400, Rob Kinyon wrote:
> 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

Or, more generally, it (the newer version) attempts to provide a
framework for building solutions that address those use cases and others.

Tim.

> 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