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 :)

cake bake model User
cake bake controller Users scaffold
cake bake view Users

For more details on those shortcuts call the bake script with the help parameter like:

cake bake model help

or have a look at Faster baking of controllers with the bake shell script and Baking views.

Recently, a new shortcut was added which makes the aforementioned shortcuts (almost) obsolete. With the “all” parameter it is now possible to bake with one command a model plus the corresponding controller with its views:

cake bake all  // asks you for the model name
cake bake all User

This feature is currently only available in the development branch, but the next release is probably not that far away…

Happy baking :)

As I didn’t understood what his script did nor how to use it, Travis explained it in the following way:

It [the bash completion script] gives you bash completion (through hitting tab) for shells and for the bake it gives you bake actions and will autocomplete potential model/view/controller names.

Here’s an intro to bash_completion: http://www.debian-administration.org/articles/316

So,
after I source this (`. bashcompletion`, `source bashcompletion`, or link it in the right location -> /etc/bash_completion.d/) I can type

`(path to console)/cake [tab][tab]`

and it lists the potential shells to use e.g. acl, api, bake (even app-specific shells)

`/cake b[tab]` -> completes 'bake'

`/cake bake m[tab]` -> completes 'model'

If I further do

`/cake bake model M[tab][tab]` it'll complete for models beginning with 'M'

It’s pretty crude atm — doesn’t handle -app params (you can invoke the console within the custom app dir for now).

If bake.php/shell is enhanced to support public, noninteractive listing this could be pretty sweet.

The bash completion provided by this script when using the CakePHP console is really handy. Thanks Travis!

php bake.php -app /path_to_app_dir

you now have to use

./cake bake -app /path_to_app_dir

to run the bake script. The ACL script can be used in a similar way.

This switch to the new console is probably the end of bake2, as it doesn’t (yet) work with the console, and the console provides a similar functionality as bake2, i.e. the console allows you to execute your own command line scripts. In the meantime the bake2 script has been removed from the repository. (Update 2007-05-15: The bake2 script has been removed from the repository)

Writing such a command line script (or shell scripts as they are called in CakePHP) is easy, so let us write a simple script which creates a file specified by the user. The custom scripts are placed in /app/vendors/shells, if they are specific to an application, or in /vendors/shells, if they are generic.

In our case it doesn’t matter where we place the file as it is only an example, so we put it to /vendors/shells. A shell class has to extend the class “Shell” and the class name has to end with “Shell”. All public functions of a shell class are treated as “commands”, i.e. they can be called directly via command line. What the “index” function is for controllers, is the “main” function for shell scripts. It is automatically called if you don’t specify a different command.

In our case we also have to override the “initialize” function, as we don’t have a database.php file in app/config (else we would get an error). The code for our shell script is straight-forward and should be self-explanatory:

// vendors/shells/demo.php
class DemoShell extends Shell {

    function initialize() {
        // empty
    }

    function main() {
        $this->out('Demo Script');
        $this->hr();

        if (count($this->args) === 0) {
            $filename = $this->in('Please enter the filename:');
        } else {
            $filename = $this->args[0];
        }
        $this->createFile(TMP.$filename, 'Test content');
    }

    function help() {
        $this->out('Here comes the help message');
    }
}

This script can now be executed in one of the following ways:

./cake demo  // asks the user for a file name
./cake demo test.txt   // uses the specified file name
./cake demo help   // shows the help message

Happy baking :)

Update (2007-05-13): Adapted to the latest changes in the code (CakeScript has been renamed to Shell)