Development environment: Database
Handling Database Data
There is no more default sql dump in ullright. Instead we use fixture-files.
Each plugin has its own fixtures in 'plugins/pluginName/data/fixtures/'.
The fixtures are used both for the web-frontend and for the tests.
Workflow:
- svn update
- (re)build model and load current fixtures to have a clean and common development environment
- php symfony doctrine:build --all --and-load --no-confirmation
- development and addition of fixtures
- commit (of course 'test:all' before - see above!)
Handling Database Data and Structure Changes for Customer Installations
We use Doctrine migrations for changes to the database structure and data that needs to be updated also in the customer's installation.
The migration classes can be found in plugins/ullCorePlugin/lib/migrations.
Workflow:
- Create new migration class
- php symfony doctrine:generate-migration nameOfMigration
- Results in file: 1266320410_nameOfMigration.php (Timestamp varies)
- Write down the changes to the database structure and insert/update necessary data
- Take a look at existing migrations for example, also: official Doctrine documenation is helpful
- Test the migration:
- In the dev environment there is no migration version stored in the database because we use fixtures. Use the following command to "fake" the migration version in the database to the version you just developed:
- php symfony ullright:fake-migration-version 6
- This is somewhat more difficult now, since Doctrine changed from versions to timestamps. The versioning concept still applies, but you have to manually find out the version numbers: If there are six migrations, the one with the highest timestamp is 6, the oldest one is 1, ...
- Migrate one version down, to simulate the customer's database structure which hasn't got the changes yet.
- php symfony doctrine:migrate 5
- Then call the migrate command like a customer would do it to update his database structure:
- php symfony doctrine:migrate
- In the dev environment there is no migration version stored in the database because we use fixtures. Use the following command to "fake" the migration version in the database to the version you just developed: