I agree, the mysql proxy is generally the best place to start. Since it
sits inline, and it "understands" SQL, there is no need to parse/regex
each statement to figure out which connection to use based on its context.
In addition, mysql proxy would be far better with respect to performance
than an application layer solution. And, it would be easier to maintain
different evironments when the solution is not in the actual
application: development, staging, production and so on.
That said, I do think there is room for this kind of solution in Zend_Db
2.0.
-ralph
till wrote:
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.
