Changeset 4548
- Timestamp:
- 06/22/08 23:56:00 (13 months ago)
- Location:
- branches/0.11/cookbook/en
- Files:
-
- 2 modified
-
symfony-1.1-and-doctrine-migrations.txt (modified) (6 diffs)
-
symfony-1.1-and-doctrine.txt (modified) (6 diffs)
Legend:
- Unmodified
- Added
- Removed
-
branches/0.11/cookbook/en/symfony-1.1-and-doctrine-migrations.txt
r4542 r4548 11 11 </code> 12 12 13 Setting up your database13 ++ Setting up your database 14 14 15 15 First thing we need to do is define your database and create it. Edit config/databases.yml and setup your sqlite3 database. Copy and … … 24 24 </code> 25 25 26 Define your schema26 ++ Define your schema 27 27 28 28 In this example we are going to use a traditional Blog model. Open config/doctrine/schema.yml and copy and paste the yaml contents from … … 80 80 </code> 81 81 82 ++ Build Database 83 82 84 Now with one simple command Doctrine is able to create the database, the tables and load the data fixtures for you. Doctrine works 83 85 with any [PDO](http://www.php.net/pdo) driver and is able to drop and create databases for any of them. … … 117 119 >> doctrine name: php 118 120 </code> 121 122 ++ Setup Migration 119 123 120 124 Now what if a few months later you want to change the schema to split out the BlogPost.author column to an Author model that is related … … 213 217 } 214 218 215 [php]216 219 // 002_migrate_author.class.php 217 220 /** … … 254 257 Now run the following command and Doctrine will automatically perform the migration process and update the database. 255 258 259 ++ Run Migration 260 256 261 <code> 257 262 $ ./symfony doctrine-migrate frontend -
branches/0.11/cookbook/en/symfony-1.1-and-doctrine.txt
r4542 r4548 1 1 So, you want to give Doctrine a try with symfony 1.1 eh? First we will need to setup a new symfony 1.1 project and install the sfDoctrinePlugin for 1.1. Execute the following commands below and continue reading: 2 3 ++ Setup 2 4 3 5 <code> … … 43 45 </code> 44 46 47 ++ Setup Database 48 45 49 Now lets setup our database configuration in `config/databases.yml`. Open the file in your favorite editor and place the YAML below inside. For this test we are simply using a SQLite database. Doctrine is able to create the SQLite database at the `config/doctrine.db` path for you which we will do once we setup our schema and some data fixtures. 46 50 … … 52 56 dsn: sqlite:///<?php echo dirname(__FILE__); ?>/doctrine.db 53 57 </code> 58 59 ++ Setup Schema 54 60 55 61 Now that we have our database configured, lets define our YAML schema files in `config/doctrine/schema.yml`. In this example we are setting up a simple `BlogPost` model which `hasMany` `Tags`. … … 106 112 name: php 107 113 </code> 114 115 ++ Build Database 108 116 109 117 Ok, now for the fun stuff. We have our schema, and we have some data fixtures, so lets run one single Doctrine command and create your database, generate your models, create tables and load the data fixtures. … … 153 161 Now, lets do a little explaining of the data that was returned. As you can see the models have a created_at, updated_at and slug column which were not defined in the schema files. These columns are added by the behaviors attached to the schema information under the actAs setting. The `created_at` and `updated_at` column are automatically set `onInsert` and `onUpdate`, and the slug column is a url friendly string that is created from the value of the name column. Doctrine has a few behaviors that are included in core such as `Sluggable` and `Timestampable`, but the behavior system is built to allow anyone to easily write behaviors for their models to re-use over and over. 154 162 163 ++ Admin Generators 164 155 165 Now we have our data model all setup and populated with some test fixtures so lets generate an admin generator to manage the blog posts and tags. 156 166 … … 202 212 All of the features you get in Propel work 99% the same way with Doctrine, so it should be fairly easy to get the hang of if you are coming from propel. sfDoctrinePlugin implements all the same functionality as sfPropelPlugin as well as several additional features which sfPropelPlugin is not capable of. Below you can find some more information on the major features that Doctrine supports: 203 213 214 ++ Helpful Links 215 204 216 * Behaviors - http://www.phpdoctrine.org/documentation/manual/0_11?chapter=plugins - Easily create reusable behaviors for your Doctrine models. 205 217 * Migrations - http://www.phpdoctrine.org/documentation/manual/0_11?chapter=migration - Deploy database schema changes to your production environment through a programmatic interface.
