[Dbix-class] DBIC::Storage::DBI::Replication RFC

[John Napiorkowski]

So I've been hacking on the replication storage and running into the following issue.  When setting a connection that 'normal', the storage method 'connect_info' takes (and returns) an arrayref like:

...->connect_info([ $dsn, $user, $pass, \%opts ]);

Which is a pretty standard bit of info, since it's basically what DBI expects and we are all used to dealing with that.

Now the replicated storage changes this around in that it takes it's params in the form of an arrayref of arrayrefs, like:

...->connect_info([ 
   [$master, $user, $pass, \%opts ]
   [$slave1, $user, $pass, \%opts ]
   [$slave2, $user, $pass, \%opts ]
   <etc>
]);


The problem here (for my application at least) is that for a lot of scripts and for some other DBIC bits (like Versioning and Fixtures) I am getting lots of errors when something is querying connect_info, expects an arrayref but gets something else.

The way connection information needs to be normalized in such as way as to not break this kind of backward compatibility.  Also, I don't think it's such a good idea to overload a method with such different types of non compatible input, particularly since it's also an accessor, since it promotes tight coupling between non related component.  For example, anyone that used ->connect_info would have to explicitly check for both return types (both arrayref and arrayref of arrayrefs) even if they didn't use replication.

So I suggest we normalize this Replication class back to the original behavior, and either add the slave info as additional arguments, or in the \%opts like DBD::Multi (the class this is all built upon).

I realize this suggestion would break backward compatibility so I am ready to hear your suggestions and feedback.  However, after trying for three days to get Replication working correctly on our largish Catalyst driven website, I think the problems I've mentioned would affect lots of people who start to look at replication to solve there scaling needs.  I think having a solid and well tested solution for this problem would be a big win for the DBIC community.

I wasn't around when the choice to make it like this was made, and maybe there are good reasons for it.  In which case I hope to hear it.  In any case I am volunteering (and actively working on this) to make this happen.

Thanks!
John


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ