Doctrine offers a way of setting column aliases. This can be very useful when you want to keep the application logic separate from the database logic. For example if you want to change the name of the database field all you need to change at your application is the column definition.
One problem with database compatibility is that many databases differ in their behaviour of how the result set of a query is returned. MySQL leaves the field names unchanged, which means if you issue a query of the form "SELECT myField FROM ..." then the result set will contain the field 'myField'.
Unfortunately, this is just the way MySql and some other databases do it. Postgres for example returns all field names in lowercase whilst Oracle returns all field names in uppercase. "So what? In what way does this influence me when using Doctrine?", you may ask. Fortunately, you don't have to bother about that issue at all.
Doctrine takes care of this problem transparently. That means if you define a derived Record class and define a field called 'myField' you will always access it through $record->myField (or $record['myField'], whatever you prefer) no matter whether you're using MySQL or Postgres or Oracle etc.
In short: You can name your fields however you want, using under_scores, camelCase or whatever you prefer.
> Data types are a way to limit the kind of data that can be stored in a table. For many applications, however, the constraint they provide is too coarse. For example, a column containing a product price should probably only accept positive values. But there is no standard data type that accepts only positive numbers. Another issue is that you might want to constrain column data with respect to other columns or rows. For example, in a table containing product information, there should be only one row for each product number.
Doctrine allows you to define *portable* constraints on columns and tables. Constraints give you as much control over the data in your tables as you wish. If a user attempts to store data in a column that would violate a constraint, an error is raised. This applies even if the value came from the default value definition.
Doctrine constraints act as database level constraints as well as application level validators. This means double security: the database doesn't allow wrong kind of values and neither does the application.
+++ Notnull
A not-null constraint simply specifies that a column must not assume the null value. A not-null constraint is always written as a column constraint.
The following definition uses a notnull constraint for column {{name}}. This means that the specified column doesn't accept null values.
When this class gets exported to database the following SQL statement would get executed (in MySQL):
<code type="sql">
CREATE TABLE user (name VARCHAR(200) NOT NULL, PRIMARY KEY(name))
</code>
The notnull constraint also acts as an application level validator. This means that if Doctrine validators are turned on, Doctrine will automatically check that specified columns do not contain null values when saved.
If those columns happen to contain null values {{Doctrine_Validator_Exception}} is raised.
+++ Unique
Unique constraints ensure that the data contained in a column or a group of columns is unique with respect to all the rows in the table.
In general, a unique constraint is violated when there are two or more rows in the table where the values of all of the columns included in the constraint are equal. However, two null values are not considered equal in this comparison. That means even in the presence of a unique constraint it is possible to store duplicate rows that contain a null value in at least one of the constrained columns. This behavior conforms to the SQL standard, but some databases do not follow this rule. So be careful when developing applications that are intended to be portable.
The following definition uses a unique constraint for column {{name}}.
>> Note: You should only use unique constraints for other than primary key columns. Primary key columns are always unique.
The following definition adds a unique constraint for columns {{name}} and {{age}}.
<code type="php">
class User extends Doctrine_Record
{
public function setTableDefinition()
{
$this->hasColumn('name', 'string', 200);
$this->hasColumn('age', 'integer', 2);
$this->unique(array('name', 'age'));
}
}
</code>
+++ Check
Some of the Doctrine validators also act as database level check constraints. When a record with these validators is exported additional CHECK constraints are being added to CREATE TABLE statement.
Consider the following example which uses 'min' validator:
Lastly you can create any kind of CHECK constraints by using the check() method of the Doctrine_Record. In the last example we add constraint to ensure that price is always higher than the discounted price.
> NOTE: some databases don't support CHECK constraints. When this is the case Doctrine simple skips the creation of check constraints.
If the Doctrine validators are turned on the given definition would also ensure that when a record is being saved its price is always greater than zero.
If some of the prices of the saved products within a transaction is below zero, Doctrine throws Doctrine_Validator_Exception and automatically rolls back the transaction.
Indexes are used to find rows with specific column values quickly. Without an index, the database must begin with the first row and then read through the entire table to find the relevant rows.
The larger the table, the more this consumes time. If the table has an index for the columns in question, the database can quickly determine the position to seek to in the middle of the data file without having to look at all the data. If a table has 1,000 rows, this is at least 100 times faster than reading rows one-by-one.
Indexes come with a cost as they slow down the inserts and updates. However, in general you should **always** use indexes for the fields that are used in SQL where conditions.
+++ Adding indexes
You can add indexes by simple calling {{Doctrine_Record::index('indexName', $definition)}} where {{$definition}} is the definition array.
An example of adding a simple index to field called {{name}}:
Doctrine offers many index options, some of them being db-specific. Here is a full list of available options:
<code>
sorting => string('ASC' / 'DESC')
what kind of sorting does the index use (ascending / descending)
length => integer
index length (only some drivers support this)
primary => boolean(true / false)
whether or not the index is primary index
type => string('unique', -- supported by most drivers
'fulltext', -- only availible on Mysql driver
'gist', -- only availible on Pgsql driver
'gin') -- only availible on Pgsql driver
</code>
<code type="php">
class MultipleIndexTest extends Doctrine_Record
{
public function setTableDefinition()
{
$this->hasColumn('name', 'string');
$this->hasColumn('code', 'string');
$this->hasColumn('age', 'integer');
$this->index('myindex', array(
'fields' => array(
'name' =>
array('sorting' => 'ASC',
'length' => 10),
'code'),
'type' => 'unique',
));
}
}
</code>
+++ Special indexes
Doctrine supports many special indexes. These include Mysql FULLTEXT and Pgsql GiST indexes. In the following example we define a Mysql FULLTEXT index for the field 'content'.
$this->hasColumn('address2', // name of the column
'string', // column type
'200', // column length
// validators / constraints without arguments can be
// specified also as as string with | separator
'notblank|email'
);
// Doctrine even supports the following format for
// validators / constraints which have no arguments:
$this->hasColumn('address3', // name of the column
'string', // column type
'200', // column length
array('notblank', 'email')
);
}
}
</code>
Note that validators / column constraints and the column length fields are optional. The length may be omitted by using **null** for the length argument, allowing doctrine to use a default length and permitting a fourth argument for validation or column constraints.
Doctrine supports many kind of identifiers. For most cases it is recommended not to specify any primary keys (Doctrine will then use field name {{id}} as an autoincremented primary key). When using table creation Doctrine is smart enough to emulate the autoincrementation with sequences and triggers on databases that doesn't support it natively.
+++ Natural
Natural identifier is a property or combination of properties that is unique and non-null. The use of natural identifiers is encouraged.
Autoincrement primary key is the most basic identifier and its usage is strongly encouraged. Sometimes you may want to use some other name than {{id}} for your autoinc primary key. It can be specified as follows:
You should consider using autoincremented or sequential primary keys only when the record cannot be identified naturally (in other words it doesn't have a natural identifier).
The following example shows why natural identifiers are more efficient.
Consider three classes Permission, Role and RolePermission. Roles having many permissions and vice versa (so their relation is many-to-many). Now lets also assume that each role and permission are naturally identified by their names.
Now adding autoincremented primary keys to these classes would be simply stupid. It would require more data and it would make the queries more inefficient. For example fetching all permissions for role 'Admin' would be done as follows (when using autoinc pks):
<code type="sql">
SELECT p.*
FROM Permission p
LEFT JOIN RolePermission rp ON rp.permission_id = p.id
LEFT JOIN Role r ON rp.role_id = r.id
WHERE r.name = 'Admin'
</code>
Now remember sql JOINS are always expensive and here we are using two of those. When using natural identifiers the query would look like:
<code type="sql">
SELECT p.*
FROM Permission p
LEFT JOIN RolePermission rp ON rp.permission_name = p.name
WHERE rp.role_name = 'Admin'
</code>
Thats -1 JOIN !
+++ Composite
Composite primary key can be used efficiently in association tables (tables that connect two components together). It is not recommended to use composite primary keys in anywhere else as Doctrine does not support mapping relations on multiple columns.
Due to this fact your doctrine-based system will scale better if it has autoincremented primary key even for association tables.
Doctrine supports sequences for generating record identifiers. Sequences are a way of offering unique IDs for data rows. If you do most of your work with e.g. MySQL, think of sequences as another way of doing {{AUTO_INCREMENT}}.
Doctrine knows how to do sequence generation in the background so you don't have to worry about calling database specific queries - Doctrine does it for you, all you need to do is define a column as a sequence column and optionally provide the name of the sequence table and the id column name of the sequence table.
By default Doctrine uses the following format for sequence tables {{[tablename]_seq}}. If you wish to change this you can use the following piece of code to change the formatting:
Doctrine uses column named id as the sequence generator column of the sequence table. If you wish to change this globally (for all connections and all tables) you can use the following code:
In the following example we do not wish to change global configuration we just want to make the {{id}} column to use sequence table called {{book_sequence}}. It can be done as follows:
Doctrine automatically creates table names from the record class names. For this reason, it is recommended to name your record classes using the following rules:
* Use {{CamelCase}} naming
* Underscores are allowed
* The first letter must be capitalized
* The class name cannot be one of the following (these keywords are reserved in DQL API):
