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

Paul Makepeace paulm at paulm.com
Sat Sep 9 23:53:32 CEST 2006


Good to see people looking into this...

On 9/8/06, Rob Kinyon <rob.kinyon at gmail.com> wrote:
> mst asked me to write up a justification as to why DBD::Multiplex
> should be completely disregarded when developing the master/slave
> round-robin code.

As one of people that saw Tim's talk at YAPC::Europe about this (and
then mentioned it to mst, oops :-)) I am not surprised by your
findings - the point of DBD::M is not really that useful for DBIC as
it stands as its use case(s) is somewhat muddled and different to
probably what most people would generally want from some kind of >1
$dbh setup.

It seems to me it'd be much easier than having the DBD layer guess
what's going on to put the selection of ro v rw handles into DBIC
direct based on the richer semantics available in the ORM.

Even something that wasn't attempting failover that had a single
$dbh_rw handle and @dbh_ro that it randomly picked from would be
great. If a transaction were on go via $dbh_rw. I for one could use
this right now; are there any plans to implement something basic like
this to begin with? I'd be happy to contribute with either code or
cash sponsoring someone.

P

> I was asked to look at added transactional capabilities to
> DBD::Multiplex when dealing with master-slave situations. When I dove
> in, I found a complete mess. Basically, the structure is as follows:
>
> 1) You create a set of $dbh's and designate one as the master.
> 2) It kinda does the right thing when dealing with prepare().
> 3) The multiplexing code is identical regardless of whether you're
> multiplexing over a drh, dbh, or sth.
> 4) There is no round-robining - it's just broadcast, broadcast to
> masters, or broadcast to slaves.
> 5) There are no tests. I started writing some tests and found bugs
> everywhere I looked.
> 6) There are no comments.
>
> #3 is the biggest issue - $dbh's and $sth's are treated identically
> when they cannot be.
>
> Frankly, it would be faster to just create a new DBD::Multiplex from
> scratch, taking lessons learned, than to attempt to clean up the
> current DBD::Multiplex.
>
> Thanks,
> Rob



More information about the Dbix-class mailing list