But what’s the difference between “updated” and “modified”? Well, there is none. You can either use “updated” or “modified”, just don’t use both as that is redundant. And whichever column name you choose, use it throughout your database to be consistent!

In the meantime there is also a migrations-like feature in the Cake core, even though it seems to be a bit half-baked (or maybe I’m too stupid to understand it *g*).

Anyway, let’s have a look at it by using the traditional blog example.

First, we create a file which will contain the definitions for our schema. We name the file blog.php and place it in app/config/sql. In this file we create a class BlogSchema:

class BlogSchema extends CakeSchema {
}

Each property of a schema class represents a table, i.e. the property name is the table name, and the property value contains the table definition as an array. The definition for our posts table looks like:

class BlogSchema extends CakeSchema {
    public $posts = array(
        'id' => array('type' => 'integer', 'null' => false, 'default' => NULL, 'key' => 'primary'),
        'title' => array('type' => 'string', 'null' => false, 'length' => 100),
        'content' => array('type' => 'text', 'null' => false),
        'indexes' => array('PRIMARY' => array('column' => 'id', 'unique' => 1))
    );
}

Now, we can switch to the command line and make a test run to verify the schema script will execute the correct SQL statements:

cd cake/console
./cake schema run create blog -dry

---------------------------------------------------------------
Cake Schema Shell
---------------------------------------------------------------
Performing a dry run.

The following tables will drop.
posts

Are you sure you want to drop the tables? (y/n)
[n] > y
Dropping tables.
Dry run for posts :
DROP TABLE IF EXISTS `posts`;

The following tables will create.
posts

Are you sure you want to create the tables? (y/n)
[y] > y
Creating tables.
Dry run for posts :
CREATE TABLE `posts` (
        `id` int(11) NOT NULL AUTO_INCREMENT,
        `title` varchar(100) NOT NULL,
        `content` text NOT NULL,
        PRIMARY KEY  (`id`)
);

End create.

Everything looks fine, so we can run the same command again, this time without the -dry parameter, and it should create the posts table.

Ok, now let’s add a new column “created” to our schema:

class BlogSchema extends CakeSchema {
    public $posts = array(
        'id' => array('type' => 'integer', 'null' => false, 'default' => NULL, 'key' => 'primary'),
        'title' => array('type' => 'string', 'null' => false, 'length' => 100),
        'content' => array('type' => 'text', 'null' => false),
        'created' => array('type' => 'datetime'),
        'indexes' => array('PRIMARY' => array('column' => 'id', 'unique' => 1))
    );
}

To introduce the new column we could use the command from above, which drops the table and recreates it. Or we could use the update command, which performs an “ALTER TABLE” statement to synchronize the posts table in the database with the posts table from the schema file:

./cake schema run update blog

---------------------------------------------------------------
Cake Schema Shell
---------------------------------------------------------------
Comparing Database to Schema...

The following statements will run.
ALTER TABLE `posts`
        ADD `created` datetime DEFAULT NULL;

Are you sure you want to alter the tables? (y/n)
[n] > y

Updating Database...
posts updated.
End update.

With that, our blog database is up-to-date.

Unfortunately, the update command doesn’t work if you add a new table to the schema file, it doesn’t create this new table in the database. And so I think the migration process is currently not that useful in practice…

I used a question mark in the title of this article, as I am not sure if what I described here is really the correct way to use the schema feature. Please correct me, if I am wrong :)

I like this idea, as it allows you to work on a higher level, i.e. you no longer have to deal with foreign keys, association tables etc. That’s automatically done for you. And the more I think about this topic, the more I am convinced that the table definition should be in the model. You can look at the column types of a table as basic “validation rules” used by the database to check whether the data you want to insert are correct. For example, a column type of varchar(255) could be translated to the validation rule “maxLength = 255″. By moving those “validation rules” to the model level, we have all validation rules related to a model in one place. And that’s the logical place where they should be in my opinion.

What do you think about this idea?

Update (2006-12-02): I forgot to mention that the Oracle support has been contributed by Jeff Loiselle (aka phishy).

Update (2006-12-04): The Oracle driver has been removed from trunk and the 1.1.x.x branch. It is still available in the 1.2 branch.

And so I am back to Apache Ant and the good old SQL scripts ;-) My approach follows a simple pattern after a modification of the SQL scripts: drop, create and insert. Here is the Ant script I use:

<?xml version="1.0"?>
<project name="myproject" default="default">
  <property name="driver" value="com.mysql.jdbc.Driver"></property>
  <property name="url" value="jdbc:mysql://localhost/myproject?characterEncoding=UTF-8"></property>
  <property name="user" value="root"></property>
  <property name="password" value=""></property>

  <target name="default" >
    <sql driver="${driver}" password="${password}" url="${url}" userid="${user}" src="drop.sql" encoding="UTF-8"></sql>
    <sql driver="${driver}" password="${password}" url="${url}" userid="${user}" src="create.sql" encoding="UTF-8"></sql>
    <sql driver="${driver}" password="${password}" url="${url}" userid="${user}" src="insert.sql" encoding="UTF-8"></sql>
  </target>
</project>

This script I can then execute with one mouse click directly from my IDE. Simple and fast.

Well, today I saw a solution, presented by nate in a post in the google group:

// app/app_model.php
class AppModel extends Model
{
    function __construct()
    {
        parent::__construct();
        $this->execute("Set NAMES 'UTF8'");
    }
}

But what to do if you want to separate your data from the session data for some reason? Well, you need two database configurations in app/config/database.php. The “default” configuration must point to the database for the sessions as the session component uses the “default” configuration (it is hardcoded). For the second database configuration you can choose any name. You have to add this name to your app/app_model.php like:

class AppModel extends Model
{
    var $useDbConfig = 'mydb';
}

That’s it. Thanks to PhpNut for the explanations, and to alexfill for asking questions.

var $test    =  array('driver'    => 'mysql',
                      'connect'  => 'mysql_pconnect',
                      'host'     => 'localhost',
                      'login'    => 'user',
                      'password' => 'password',
                      'database' => 'project_name-test',
                      'prefix'    => '');

But it does not automatically use the “test” configuration when I run a test. So I wrote a constructor for app/config/database.php based on the idea from http://wiki.cakephp.org/tutorials:change_database_config, which switches the database configuration based on the request url (thanks to gwoo for the hint):

function __construct ()
{
    if (strstr($_SERVER['REQUEST_URI'], '/tests'))
    {
        $this->default = $this->test;
    }
}