On Fri, Sep 08, 2006 at 08:15:15PM -0400, Rob Kinyon wrote: > 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
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 _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
