Skip Menu |

This queue is for tickets about the DBD-Multi CPAN distribution.

Report information
The Basics
Id: 30250
Status: resolved
Priority: 0/
Queue: DBD-Multi

People
Owner: Nobody in particular
Requestors: Dan [...] DWright.Org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [Fwd: Re: [Dbix-class] Replication]
Date: Wed, 24 Oct 2007 18:26:24 -0400 (EDT)
To: bug-dbd-multi [...] rt.cpan.org
From: "Daniel J. Wright" <Dan [...] DWright.Org>
Show quoted text
---------------------------- Original Message ---------------------------- Subject: Re: [Dbix-class] Replication From: "Tim Bunce" <Tim.Bunce@pobox.com> Date: Wed, October 24, 2007 6:05 pm To: "DBIx::Class user and developer list" <dbix-class@lists.scsys.co.uk> Cc: jspath@pangeamedia.com Dan@DWright.Org -------------------------------------------------------------------------- On Wed, Oct 24, 2007 at 08:18:51PM +0100, Matt S Trout wrote:
> On Wed, Oct 24, 2007 at 11:37:50AM -0400, Jim Spath wrote:
> > What is the current state of replicated database support in DBIx::Class? > > > > We are considering creating a master/slave setup with our MySQL > > database, but weren't sure if it would be easy to support it in our > > Catalyst/DBIx::Class applications. > > > > From previous discussions on the list, it seems like DBD::MultiPlex is > > out of favor? > > > > I searched CPAN and found DBIx::Class::Storage::DBI::Replication, which > > utilizes DBD::Multi. It's labeled as experimental, which makes me > > nervous about using it in a production enviroment, but it sounds like > > exactly what I am looking for. Is it stable?
> > The authors are using it in production. > > They did not, however, write any tests for it. At all. > > So I marked it EXPERIMENTAL on the grounds that the plural of anecdote is > not data. > > A client of Shadowcat's is also interested in this soon; much though I
dislike
> being commercial on this list now would be a really good time for people
who
> care about this to mail me at my work address and I'll see about organising > one of the DBIC contribs we contract to do some sponsored test-writing
split
> between all the commercial interests involved.
With a small change to DBD::multi it should be possible to use the DBI test suite to test the "transparency" of DBD::Multi. In theory you could just do this: DBI_AUTOPROXY='dbi:Multi:' make test The only change needed would be for DBD::Multi to support this syntax DBI->connect("dbi:Multi:dsn=$the_dsn_to_connect_to", $user, $pass) I'd highly recommend it. It's a great way to give 'transparent plumbing' drivers like this a work out. The DBI uses the same mechanism to test DBD::Gofer and I can vouch for the fact that it's brutally effective at spotting all sorts of edge cases. (I've not done any coverage analysis recently but I'm sure there are many large gaps. That doesn't stop this approach being very helpful.) Tim.
Borrowing from the current synopsis: my $dbh = DBI->connect( 'dbi:Multi:', undef, undef, { dsns => [ # in priority order 10 => [ 'dbi:SQLite:read_one.db', '', '' ], 10 => [ 'dbi:SQLite:read_two.db', '', '' ], Here's what needs to happen: 1) Allow specification of "dbi:Multi:$dsn". If a dsn is included on this string, it gets priority zero (top priority). 2) Allow specification of user and pass in the DBI->connect() line. - Does this only apply to the $dsn? - Should it also be considered a "Default" for the other dsn's?
Fixed in revision 0.13