New in Drupal 7 ( Part 2)

There are a lot of new things for developers to take advantage of in Drupal 7. These sometimes replace the functionality that was available in Drupal 6 with new functions or hooks, and sometimes implement new functionality.

Master/Slave Replication

In Drupal 6, support for Master/Slave database replication could only be implemented by using a distribution such as Pressflow, but Drupal 7 natively supports replication.

The Drupal 7 query system allows queries to have attributes that direct the target of a query.

Brad Blake
#Drupal | Posted

There are a lot of new things for developers to take advantage of in Drupal 7. These sometimes replace the functionality that was available in Drupal 6 with new functions or hooks, and sometimes implement new functionality.

Master/Slave Replication

In Drupal 6, support for Master/Slave database replication could only be implemented by using a distribution such as Pressflow, but Drupal 7 natively supports replication.

The Drupal 7 query system allows queries to have attributes that direct the target of a query. If the target was set to a slaver server and no such server is configured or the server is not available, Drupal will default to using the master database.

In order to take advantage of this new functionality, module developers should add parameters to their queries when they are sure that the queries are safe to always be read by slave servers rather than from the master server.

For example, the following line will allow the query to be split off to a slave server if one is available.

$query = db_select('node', 'n', array('target' => 'slave'));

Views has a slave server option as well. If you navigate to the edit page for a view in the administration interface, under Advanced Settings -> Query Settings there is an option to “Use Slave Server”. By default, this option is not checked. Checking it will ensure that the query for that particular view or display will be split off to a slave server.

Query Changes

There are new functions to use for each type of query as well. Developers can still use db_query, although the parameters have changed.

However, in order to write queries that other modules can alter, select queries should be made by using db_select, which creates a new select query object that can be manipulated using query_alter hooks.

  1. $query = db_select('node', 'n', array('target' => 'slave'));
  2. $query->innerJoin('field_data_field_taxonomy_term', 't', 'n.nid = t.entity_id');
  3. $result = $query->fields('n', array('nid'))
  4. ->condition('n.status', 0, '<>')
  5. ->condition('t.field_taxonomy_term_tid', $tid)
  6. ->execute()
  7. ->fetchCol();

Functions such as inserts, updates and deletes can be done with similar functions.

  1. db_insert('table')
  2. ->fields(array(
  3. 'pid' => $pid,
  4. 'rid' => $rid,
  5. ))
  6. ->execute();
  7.  
  8. db_update('table')
  9. ->fields(array(
  10. 'name' => $name,
  11. 'description' => $description,
  12. ))
  13. ->condition('nid', $nid)
  14. ->execute();
  15.  
  16. db_delete('table')
  17. >condition('pid', $pid)
  18. ->execute();

These functions should always be used instead of db_query for the INSERT, UPDATE and DELETE queries in order to let those functions take care of creating the correct syntax for the database the site is using.

For more information on the Drupal 7 query system, check out this link.

Brad Blake

Brad Blake