We work with Phing‘s dbdeploy task to do version control of our PostgreSQL databases, which altogether is a nice way of working. I don’t really have a lot of problems with database versions after we started working with it, apart from one nagging doubt: how do we control the data the database contains?
Right now, I usually have a delta that contains some example data, which is used for testing, but in a production environment, I want to have production data, as in, actual valid data. Of course, I could write another delta which truncates the testdata and insert the actual data, but somehow that feels clunky and cumbersome, as the only language in a delta is SQL. When writing such a delta, handling sequences and making sure foreign key relations are correct, is a real pain.
So I figured it might make sense to write a PHP script that will import data from, say, a CSV file. That would actually work, until there is another database change that renames a column, which would render the PHP file useless. Of course, that is easily fixed by updating the script to incorporate the database changes and re-running the script, but that’s error-prone, which sort of is the reason I started using dbdeploy in the first place.
So, my question is; how do you handle data while deploying changes, or more accurately: how do you insert the data the production environment needs?
You’re right that testing data should be left out of deltas the same way testing shouldn’t probably be done on a production system. What do you use for testing? Phpunit, Selenium, …? Do you use any php framework?
Anyway the best way may be using something that might already come shipped with whatever tool you happen to be using. For example Symfony 1.x has quite a good fixture management. For testing PHP code, PHPUnit is a de facto standard and it comes with some fixture management. Try looking at the PHPUnit documentation for more info on how it handles datasets: http://www.phpunit.de/manual/current/en/database.html#understanding-datasets-and-datatables