Reference

A Drupal schema definition is an array structure representing one or more tables and their related keys and indexes. A schema is defined by hook_schema(), which usually lives in a modulename.install file. hook_schema() should return an array mapping 'tablename' => array(table definition) for each table that the module defines. The following keys in the table definition are processed during table creation:

  • 'description': A string describing this table and its purpose. References to other tables should be enclosed in curly-brackets. For example, the node_revisions table description field might contain "Stores per-revision title and body data for each {node}."
  • 'fields': An array mapping 'fieldname' => array(field definition) that describes the table's database columns. The specification is also an array. The following specification parameters are defined:
    • 'description': A string describing this field and its purpose. References to other tables should be enclosed in curly-brackets. For example, the node table vid field description might contain "Always holds the largest (most recent) {node_revisions}.vid value for this nid."
    • 'type': The generic datatype: 'varchar', 'int', 'serial', 'float', 'numeric', 'text', 'blob' or 'datetime'. The types map to the underlying database engine specific datatypes. Use 'serial' for auto incrementing fields.
    • 'size': The data size: 'tiny', 'small', 'medium', 'normal', 'big'. This is a hint about the largest value the field will store and determines which of the database engine specific datatypes will be used (e.g. on MySQL, TINYINT vs. INT vs. BIGINT). 'normal', the default, selects the base type (e.g. on MySQL, INT, VARCHAR, BLOB, etc.).

      TO DO: Add a page defining all type:size maps for each supported database.

    • 'not null': If true, no NULL values will be allowed in this database column. Defaults to false.
    • 'default': The field's default value. The PHP type of the value matters: '', '0', and 0 are all different. If you specify '0' as the default value for a type 'int' field it will not work because '0' is a string containing the character "zero", not an integer.

      Note that type 'text' and 'blob' fields cannot have default values.

    • 'length': The maximal length of a type 'varchar' or 'text' field. Ignored for other field types.
    • 'unsigned': A boolean indicating whether a type 'int', 'float' and 'numeric' only is signed or unsigned. Defaults to FALSE. Ignored for other field types.
    • 'precision', 'scale': For type 'numeric' fields, indicates the precision (total number of significant digits) and scale (decimal digits right of the decimal point). Both values are mandatory. Ignored for other field types.

    All parameters apart from 'type' are optional except that type 'numeric' columns must specify 'precision' and 'scale'.

  • 'primary key': An array of one or more key column specifers that form the primary key.
    • A key column specifier is either a string naming a field or an array of two elements, a string naming a field and an integer prefix length. If a prefix length is specified, only that many bytes or characters of the named field are used as part of the key. If the database engine does not support this optimization, the prefix length is ignored.
    • All fields listed in the primary key must have 'not null' => TRUE in their specification.
  • 'unique keys': An associative array of unique keys ('keyname' => specification). Each specification is an array of one or more key column specifiers (see above) that form a unique key on the table.
  • 'indexes': An associative array of indexes ('indexame' => specification). Each specification is an array of one or more key column specifiers (see above) that form an index on the table.

Note that type 'text' and

yched - May 27, 2007 - 10:30

Note that type 'text' and 'blob' fields cannot have default values
Is this structurally true whatever the db type, or only for MySQL ?

Also, something like "the 'not null' value will be ignored for text and blob fields" would probably be clearer.

required parameters for field arrays

bec - December 12, 2007 - 06:18

I might suggest that

All parameters apart from 'type' are optional except that type 'numeric' columns must specify 'precision' and 'scale'.

should be amended to also note that type 'varchar' columns must specify 'length'.

No 'bool' type

Pancho - December 13, 2007 - 22:46

Note that there is no generic datatype 'bool'.
Instead you have to use something like type 'int' with size 'tiny' (aka tinyint in MySQL).

Hmm...

NancyDru - December 22, 2007 - 17:38

The schema module generates a field called 'disp-width' but it is not documented here?

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

disp-width

Robert Castelo - May 10, 2008 - 20:53

"disp-width: The display width of non-varchar columns for the mysql command-line client. Only used by MySQL."
http://jaspan.com/schema-project-status-report

Length ? Size? Char?

sumgai - February 15, 2008 - 18:26

I'm a little confused by the documentation for length vs. size.

I assume that you use 'length' for numerical values, e.g., char(4), but it doesn't specify this for char anywhere.

BTW - I think it would have been simpler to just have a single attribute, 'size', and allow it to have numeric values for 'varchar', 'text' and 'char'.

Well...

NancyDru - February 15, 2008 - 18:37

"Size" is alphabetic ("tiny," "medium," etc.) and suggests the size of the column.

"Length" is numeric and exactly specifies the maximum length of the column.

Since "char" is always padded on the right with spaces, I would not recommend its use. Use "varchar" instead.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

There are times when char is needed

sumgai - February 27, 2008 - 17:06

char is a very useful type and more efficient than varchar for small strings.

It's very common to use fixed-length char fields for product ids and many other applications.

But the real points of my post are:

  • the documentation was confusing and didn't address clearly the use of "length" for char fields. If you read above, you'll see that it says the "length" field is ignored for everything except text and varchar fields.
  • my humble opinion is that it is unnecessarily complex and cumbersome to have both "size" and "length" when just one would suffice (which could be a string or an integer value).

tnx

 
 

Drupal is a registered trademark of Dries Buytaert.