Zend Framework 1 and Doctrine 2 integration – modular setup

Elink Media posts a followup;

I’ve created a new branch on my Github project “zf1-doctrine2″. The “modular_setup” branch shows how we could setup Zend Framework with the modular approach, while still be able to use Doctrine 2 as the ORM for each module.

Oh well, the idea is to make each module decoupled with the rest of the application, so really, you could use whatever database handling mechanism in each module.

Check it out from my Github project here.

Reference

via Zend Framework 1 and Doctrine 2 integration – modular setup.

Akrabat_Db_Schema_Manager: table prefix support

Rob Allen posts; I’ve updated Akrabat_Db_Schema_Manager so that it now supports table prefixes.

It uses the application.ini key of resources.db.table_prefix as I couldn’t think of a better one 🙂 and then uses that for the schema_version table’s name and also makes it available in your change objects.

For example, if application.ini contains resources.db.table_prefix = “myapp”, then the manager will create the table myapp_schema_version to store the current version of the schema. In your change classes, you can then do this:

001-Users.php:

class Users extends Akrabat_Db_Schema_AbstractChange
{
function up()
{
$tableName = $this->_tablePrefix . 'users';
$sql = "
CREATE TABLE IF NOT EXISTS $tableName (
id int(11) NOT NULL AUTO_INCREMENT,
username varchar(50) NOT NULL,
password varchar(75) NOT NULL,
role varchar(200) NOT NULL DEFAULT 'user',
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;";
$this->_db->query($sql);

$data = array();
$data['username'] = 'admin';
$data['password'] = sha1('password');
$data['role'] = 'admin';
$this->_db->insert($tableName, $data);
}

function down()
{
$tableName = $this->_tablePrefix . 'users';
$sql= "DROP TABLE IF EXISTS $tableName";
$this->_db->query($sql);
}

}

which will create a table called myapp_users. Note that you are responsible for using the prefix property as the change classes cannot enforce what you do within the up() and down() methods. It also follows that you’ll have to ensure that your models also use the correct prefix.

I have also made a change to the provider (Akrabat_Tool_DatabaseSchemaProvider) so that it loads the correct application.ini file based on the data in the project’s profile. This shouldn’t affect anyone using Akrabat_Db_Schema_Manager, except that we no longer define APPLICATION_ENV and APPLICATION_PATH for you.

Enjoy!

via Rob Allen’s DevNotes.