Views Upgrade feature:
Added a new parameter to Views Version 2 which allows the designer to select the SQL query’s location. It allows him to chose the main database or the slave database.
The parameter is turned on by adding the following option to the views configuration object:
$handler->override_option('slave_db', TRUE);
It’s also been added to the Views GUI and can be turned on or off.
The Views GUI provides the SQL preview and whether it’s directed to the Master or Slave DB’s, and its execution times.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | views_2_11b.patch | 10.61 KB | miltonsp |
| #3 | views_patch.diff | 10.11 KB | miltonsp |
| #3 | ScreenHunter_20 May. 13 13.30.gif | 20.27 KB | miltonsp |
| #3 | ScreenHunter_21 May. 13 13.30.gif | 14.04 KB | miltonsp |
| views_patch.diff | 170.7 KB | miltonsp |
Comments
Comment #1
dawehnerYes needs work is the right status. 170KB of diff is not the right thing :)
Additional you need to rerole this against v3. This should be a query plugin setting.
Additional there is some debug code left.
Additional db_query_slave is not part of d6-core, but just pressflow. So this will brake some things. I guess the best way would be to just support v3 and write a additional query plugin which supports this kind of stuff but requires pressflow.
Comment #2
dawehnerIn views3 you can use hook_views_plugins_alter to change the handler of the sql query plugin. Then you can do everything you want in your own query plugin
Comment #3
miltonsp commentedThe diff file was large because of line-endings.
I am attaching an updated patch file with only 11k.
Removed the commented debugs.
Yes, it does needs db_query_slave(). In our Drupal V6 install, they all have been updated with db_query_slave and db_query_range_slave().
All medium and/or high traffic sites using Views 2, need some kind of facility that implements this feature.
Someone in the Drupal community may want to use this as a starting point.
Please see attached 2 screens.
Comment #4
miltonsp commentedComment #5
dawehnerProove this, i can give other examples.
If you add this to view 100 new issues will be there which will report: the function db_query_slave is not there.
I see no real reason for this to be on views. It's possible without a patch in views3. Old versions of software cannot have every new feature.
Comment #6
merlinofchaos commentedYou're right, this could be a useful starting point for someone...and they'll never find it in the Views issue queue. This should be placed alongside the patches that allow master/slave functionality, whereever that is.
Comment #8
bibo commentedCould you specify how this can be achieved with views 3.x? Is there some custom plugin available?
(+subscribe)
EDIT: I guess this is what I should look at:
https://wiki.fourkitchens.com/display/PF/Using+database+replication+with...
http://www.lullabot.com/articles/querying-slave-database-with-views
Comment #9
dawehnerRead http://www.lullabot.com/articles/querying-slave-database-with-views
It's possible to use on the latest version of views 3.x
Comment #10
erikwebb commentedThis should probably be re-rolled with
function_exists('db_query_slave')wrapped in each if statement to prevent errors when developing on a dev server using the same codebase but no slave server.Also, I don't believe in D6 it's safe to assume a slave is configured unlike in D7. Another test should be included to check for the existence of the $db_slave variable and that it's a populated array. Can anyone confirm if db_query_slave() gracefully degrades or not? (Doesn't appear so viewing the patch.)
Please create patches using
diff -uporsvn diff --diff-cmd diff -x -upto make for more readable diffs per Creating patches.Comment #11
miltonsp commentedI have recreated the views_db_slave.patch with the base version of Views 2.11 (Jun 16, 2010).
Comment #12
vacilando commentedCongrats, @miltonsp, for writing this patch for Views2. It is much needed by pretty much everybody that uses Pressflow as long as Views3 is in alpha stage and without documentation.