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
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
