For a CMS I’ve been working on, there are a number of custom routes that are added statically in a loop. These point to specific ID’s of articles on on the default module’s page viewing controller/action. Sometimes these routes need to appear in the Zend_Navigation output. As you can probably guess, the logic used for this is similar to what you might experience when using the URL view helper. But, for some reason, I could never get the URL’s to be marked as active.
Here is an example of the code that was being executed in the setup plugin:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | $route = new Zend_Controller_Router_Route_Static( 'custom-url-1', array( 'module'=>'default', 'controller'=>'page', 'action'=>'view', 'id'=>101, ) ); $router->addRoute('custom1', $route); $route = new Zend_Controller_Router_Route_Static( 'custom-url-2', array( 'module'=>'default', 'controller'=>'page', 'action'=>'view', 'id'=>102, ) ); $router->addRoute('custom2', $route); |
Well, it turns out that its impossible for the URL handler to know which route to use. It can match it, sure, but it doesn’t know how to recompile it (that’s my best guess at least…). So, in order to tell it to form it in the default way, I added the ‘route’=>’default’ attribute to the arrays and this seemed to work.
So now, for example, this is what you’ll find:
1 2 3 4 5 6 7 |
Hope this helps someone else out! If you know exactly why this works, feel free to comment.
It would be interesting to get some feedback from a full time DBA working with a lot of large data sets running on MySQL, but I’ll try and give any mini-insight I can.
In my adventures working at “the big L” there was a particular project which actually prompted me to read through “High Performance MySQL” from the oh so familiar O’Reilly publishing company.
The options for the problem at hand seemed to be either one of a few replication schemes or to “shard” data sets.
When you have the luxury of a development team (we do now), these scenarios can be very doable applying a method like you are exploring here OR using different database connections for different data sets (to take advantage of sharding), but then you are still stuck with single instance scalability per shard unless you break it up and add a layer of replication per shard that needs it.
The only alternative (that I’m aware of anyway) is to utilize mysql-proxy to act as your query switchboard as the fun dolphin at an old school switch board logo suggests. =P
There are a few problems or er… challenges to face going this route. The most glaring is the scary label of “alpha” on the current production release. The second is to do anything too advanced beyond the included formulas you need to pull up your boot straps and dig into LUA as that is what drives the query separation in MySQL Proxy.
Last but not least; this is not quite a viable solution (that i’ve been able to get working 100%) when dealing with things like Joomla etc. It’s nothing against the Joomla team, but the way their session handling works is that regardless of where you store the data sessions ids are always stored in the database (which probably is unavoidable anyway?); so when you request an id from a read only slave faster than replication you get a white screen of death (1% of the time this occurs, which is far to much in production).
A potential solution to this would be to try and create a MySQL Proxy formula that forces all session select queries to happen against the write master and perhaps a couple other like tweaks; If that sounds like something YOU(random reader) need then I suggest rolling up the sleeves and playing with LUA.
In closing the best solution for something that truly needs to scale is rely on smart people like Aaron and other devs to build scaling abilities via read / write splitting, utilizing sharding, and writing objects to memcache etc etc in your org’s application, as opposed to relying an “alpha” stage code base to act as query traffic cop, even if you are a rock start DBA vs a broadband generalist SysAdmin like yours truly. =)