On 9/8/06, Tim Bunce <[EMAIL PROTECTED]> 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
