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
_______________________________________________
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]/
