Now that you have a means to dump the database, you also need a means to restore it. Restoring seems rather rather simple on the surface, but there are a few things to keep an eye out for: fully updating table schema changes, and preserving working space data.

Updating table schema changes

By default, when restoring a table the existing table will be dropped and then recreated. The first issue comes when a table is dropped during development: if you do a plain restore the deleted table would remain in your MySQL database. Then, when you do a dump the table will come back and potentially get reimplemented in your version control.

The erase_database script is really just a helper for restoring. Before doing a restore, it will discover all tables that are in your MySQL database and delete them.

Preserving working space data

User data may be useless to keep in version control, but it's useful to maintain within your working space. Watchdog can help you track bugs, for example. Or, in order to avoid being forced to continually re-logged in, the sessions table would need to be preserved.

Within the configuration settings, there is a difference between what is filtered and what is filtered and preserved. The default settings will filter cache always. When restoring, then, cache will always be deleted. The filtered and preserved options will change the dump file to only create a table if it doesn't exist when it is set to be perserved. So, although data in the watchdog table is not saved in version control, the data will not be wiped from your working space when you do a restore.

This can cause some bugs, but they only effect the working space. There can be duplicate key-issues, or the schema of a table changed. When these issues happen, erasing the database completely and doing a restore would resolve them. Of course, then, the working space would lose any data it was attempting to preserve, but for most cases this is a minor or non-issue.

Using a database restore during development

The ability to dump and restore the database allows you to go back to previous versions. While developing, we can try out experimental changes and remove that experiment quickly, with no remnants, when we can just roll back to the last-good version.

Testing a configuration can be done without putting the test data into version control. After making configuration changes, you would dump the database without committing it. Perform your tests and then restore the database to remove the test data. This process can be repeated until the tests pass.

When working with multiple developers, their configuration changes will be passed to you through version control. Whenever you receive an update to the database, you must restore it.