Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Apress.Pro.Drupal.7.Development.3rd.Edition.Dec.2010.pdf
Скачиваний:
74
Добавлен:
14.03.2016
Размер:
13 Мб
Скачать
☆

CHAPTER 5 ■ WORKING WITH DATABASES

Continued

Schema Definition

 

Native Database Field Type

 

 

 

 

 

 

Type

Size

MySQL

PostgreSQL

SQLite

int

normal

INT

int

INTEGER

float

tiny

FLOAT

real

FLOAT

float

small

FLOAT

real

FLOAT

float

medium

FLOAT

real

FLOAT

float

big

DOUBLE

double

FLOAT

 

 

 

precision

 

float

normal

FLOAT

real

FLOAT

numeric

normal

DECIMAL

numeric

NUMERIC

blob

big

LONGBLOB

bytea

BLOB

blob

normal

BLOB

bytea

BLOB

datetimedatetime

norm al

DATETIME

timestamp

TIMESTAMP

 

 

 

 

 

Maintaining Tables

When you create a new version of a module, you might have to change the database schema. Perhaps you’ve added a column or added an index to a column. You can’t just drop and recreate the table, because the table contains data. Here’s how to ensure that the database is changed smoothly:

1.Update the hook_schema() implementation in your .install file so that new users who install your module will have the new schema installed. The schema definition in your .install file will always be the latest schema for your module’s tables and fields.

2.Give existing users an upgrade path by writing an update function. Update functions are named sequentially, starting with a number that is based on the Drupal version. For example, the first update function for Drupal 7 would be modulename_update_7000() and the second would be modulename_ update_7001(). Here’s an example from modules/comment/comment.install where the table used to store comments was renamed from comments to comment:

108

CHAPTER 5 ■ WORKING WITH DATABASES

/**

* Rename {comments} table to {comment}. */

function comment_update_7002() { db_rename_table('comments', 'comment');

}

3.This function will be run when the user runs http://example.com/update.php after upgrading the module.

■Caution Because the schema definition found in your hook_schema() implementation changes every time you want a new table, field, or index, your update functions should never use the schema definition found there. Think of your hook_schema() implementation as being in the present and your update functions as being in the past.

See http://drupal.org/node/150220.

A full list of functions for dealing with schemas can be found at http://api.drupal.org/api/ group/schemaapi/7.

■ Tip Drupal keeps track of which schema version a module is currently using. This information is in the system table. After the update shown in this section has run, the row for the comment module will have a schema_version value of 7002.To make Drupal forget, use the Reinstall Modules option of the Devel module, or delete the module’s row from the system table.

Deleting Tables on Uninstall

When a module is disabled, any data that the module has stored in the database is left untouched, in case the administrator has a change of heart and reenables the module. The Modules page has an Uninstall tab that automatically removes the data from the database. You might want to delete any variables you’ve defined at the same time. Here’s an example for the annotation module we wrote in Chapter 2:

/**

* Implements hook_uninstall(). */

function annotate_uninstall() {

// Clean up our entry in the variables table. variable_del('annotate_nodetypes');

}

109

Download from Wow! eBook <www.wowebook.com>

CHAPTER 5 ■ WORKING WITH DATABASES

Changing Existing Schemas with hook_schema_alter()

Generally modules create and use their own tables. But what if your module wants to alter an existing table? Suppose your module absolutely has to add a column to the node table. The simple way would be to go to your database and add the column. But then Drupal’s schema definitions, which should reflect the actual database table, would be inconsistent. There is a better way: hook_schema_alter().

Suppose you have a module that marks nodes in some way, and for performance reasons, you are dead set on using the existing node table instead of using your own table and joining it using node IDs. Your module will have to do two things: alter the node table during your module’s installation and modify the schema so that it actually reflects what is in the database. The former is accomplished with hook_install(), the latter with hook_schema_alter(). Assuming your module is called markednode.module, your markednode.install file would include the following functions:

/**

* Implements hook_install(). */

function markednode_install() { $field = array(

'type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE, 'default' => 0,

'initial' => 0, // Sets initial value for preexisting nodes. 'description' => t('Whether the node has been marked by the

markednode module.'),

);

// Create a regular index called 'marked' on the field named 'marked'. $keys['indexes'] = array(

'marked' => array('marked')

);

db_add_field('node', 'marked', $field, $keys);

}

/**

*Implements hook_schema_alter(). We alter $schema by reference.

*@param $schema

*The system-wide schema collected by drupal_get_schema().

*/

110

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]