Did any of you guys ever consider running mysql proxy[0] for this? I feel like it's the perfect solution because it does not require you to build replication into the app. Master-slave is probably simple, but let's say you have a dozen slaves and a master-master in the mix.
Till [0]: http://forge.mysql.com/wiki/MySQL_Proxy On Fri, Aug 14, 2009 at 4:12 AM, Cameron<themsel...@gmail.com> wrote: > Also, this sounds like a great idea for ZF 2.0, people are lining up a huge > list of sweeping, BC-breaking changes for the 2.0 release, why not add this > to the pile? > > On Fri, Aug 14, 2009 at 9:48 AM, johncongdon <j...@johncongdon.com> wrote: >> >> Are you able to make your solution public? I am looking for this very >> thing >> and would prefer to stand on the shoulders of giants rather than trying to >> eat a ton of calories to become one myself.... :) >> >> >> >> >> william0275 wrote: >> > >> > We are switching to a replicated database environment and I've been >> > studying the class hierarchy in the Zend Framework to find the best way >> > to >> > handle this. Since it seems ZF makes poor use of interfaces, classes >> > like >> > Zend_Db_Table checks for an instance of Zend_Db_Adapter instead of a >> > similar interface. >> > >> > I've seen solutions on the web having to do with extending >> > Zend_Db_Table. >> > >> > I think I found a better solution and would like to suggest it here for >> > people who might have the same dillema in the future. >> > >> > I think extending Zend_Db_Table is the wrong idea, because it means >> > you're >> > limited to Zend_Db_Table to handle your master/slave architecture. If >> > you >> > extend Zend_Db_Adapter instead, you will have master/slave functionality >> > at the core, not only in Zend_Db_Table. >> > >> > I did extend Zend_Db_Adapter with the concept that the instance of this >> > Zend_Db_Adapter is for the master connection, and internally I create a >> > second adapter which will be used for the slave. Methods like insert, >> > update and delete are not overriden because they always work directly >> > with >> > the master. I overrode all fetch methods (fetchAll, fetchAssoc, etc) so >> > that it uses the slave adapter instead, remapping the calls. >> > >> > I added a forceAdapter() method to force the use of the "master" >> > connection throughout a series of queries, so that in some circumstances >> > you can select data from the master to make sure you get the newly >> > updated >> > data right away. >> > >> > Now, my MyCompany_Db_Adapter_Pdo_Mysql will automatically handle reads >> > and >> > writes to the right server. When I create the instance I pass it a >> > series >> > of parameters, like before, with a new parameter called 'slave' which >> > contains it's own series of connection parameters. If the 'slave' array >> > isnt present, the adapter works the traditionnal way. >> > >> > Anyhow, unless there are other better alternatives, I suggest you do it >> > this way, you'll then be able to use this class with most Zend_Db >> > classes >> > like Zend_Db_Table. It's a shame the Zend Framework team didnt use >> > interfaces in an extensive way, I might have chosen other alternatives >> > if >> > classes like Zend_Db_Table validated the adapter against a >> > DbAdapterInterface (for example) instead of Zend_Db_Adapter. >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Handling-MySQL-replication-with-Zend_Db_Adapter-and-Zend_Db_Table-tp21812347p24964652.html >> Sent from the Zend Framework mailing list archive at Nabble.com. >> > >
