The data in these tables is kind of a prerequisite for the application to run: I must be able to have a status to assign to a user when creating it, and the same applies to roles. Sure, I could spend 20 minutes populating these tables manually, but it would be nice if there was a less tedious way, wouldn’t it?

There is indeed. The inspiration came from a technique described in the book (which I highly recommend) Agile Web Development With Rails, in which the author outlines how it would be possible to use Rails’ fixtures and migrations to load data in the database automatically from YAML files.
All you have to do is create a migration to load the specified YAML files and you’re all set.

I wanted to take a little step further, allowing the migration to load data from all YAML files in a specific directory, automatically.Let’s start creating the YAML files then and place them all in one directory of the application like /db/migrate/defaults. Here’s the one I used for user roles, for example:

visitor:
	id: 1
	name: Visitor
	level: 0

user:
	id: 2
	name: User
	level: 10

contributor:
	id: 3
	name: Contributor
	level: 20

provider:
	id: 4
	name: Provider
	level: 50

operator:
	id: 5
	name: Operator
	level: 100

administrator:
	id: 6
	name: Administrator
	level: 500

webmaster:
	id: 7
	name: Webmaster
	level: 1000

The important thing to remember is to provide a unique string to identify each record, before specifying each fiels. The other files look similar, so I won’t bother listing them here.

And here’s the simple code for the migration:

require 'active_record/fixtures'

class LoadDefaults < ActiveRecord::Migration

	def self.up
		down
		models = self.default_models
		models.each do |m|   
			Fixtures.create_fixtures(self.default_directory, m)
		end
	end

	def self.down
		models = self.default_models
		models.each do |m|
			eval("#{m.singularize.capitalize}.delete_all")
		end
	end

	def self.default_directory
		File.join(File.dirname(__FILE__), "defaults" )
	end

	def self.default_models
		files, names = Dir.glob("#{self.default_directory}/*.yml"), []
		unless files.blank?
			files.each { |f| names << File.basename(f, '.yml') }
			names
		else
			[]
		end
	end

end

Basically the migration will look in a directory named “defaults” for some YAML files named after a particular database table, and it will attempt to load all the records defined in each one of them.
The down method of the migration deletes all the data in the specified tables, so use with care…

CakePHP seems to use a multiple level database abstraction: in other words, popular abstraction layers like ADOdb or PEAR::DB have been wrapped in a “driver” which basically extends the DboSource class (which is the most high level database abstraction). Some people don’t like the idea, because this means that the could be some performance issues, for one, and also that inevitably not all features offered by either ADOdb or PEAR::DB are used. In my very, very, very modest opinion (I’m not an expert on this matter), this solution focus on achieving good database compatibility leaving the doors open for further tinkering, if needed.

Having said this, yes, the possibilities are good that your favorite database is supported by CakePHP, more or less. Of course, as repeatedly pointed out by some CakePHP core developers, Cake dev team didn’t and is not going to test every database with Cake, using either of the two abstraction layers, but users are more than welcome to do so.

Let’s now have a look at what is known to work with Cake:

MySQL works fine, and is currently recommended as preferred database solution. What about MySQLi? Well, thanks to mappleJoe there’s a (PHP5 only!) driver ready to be used.

SQLite is supported natively, or so it seems… what about the newest SQLite3? Yes, probably: there’s a quick howto on ThompsonLife.net to make it work through the dbo_pear driver.

Access works through the ADOdb driver, as reported in CakePHP wiki (thanks ivanp).

FileMaker is getting there: things aren’t that easy, but bdb is doing all his best to make it work, good luck!

Neil Fincham was also trying to develop a custom driver to support Pervasive through a unixODBC driver. Best of luck!

For other databases, check ADOdb’s list of supported databases and use the dbo-adodb driver, or use PEAR::DB (for fbsql, ibase, informix, msql, mssql, mysql, mysqli, oci8, odbc, pgsql,sqlite and sybase) using the dbo-pear driver.