The standard doens’t specify that at the moment, but it would lose some of it’s benefits if it did. Having executable SQL in the deploy file is good news.

SELECT * FROM information_schema.COLUMNS
WHERE COLUMN_NAME=’colname’ AND TABLE_NAME=’tablename’ AND TABLE_SCHEMA=’dbname’

– //@DEPLOY

CREATE TABLE `post` (
`title` VARCHAR(255),
`time_created` DATETIME,
`content` MEDIUMTEXT
);

– //@UNDO

DROP TABLE `post`;

– //

Regarding the space between the dash and the slashes, we learned this the hard way about two months ago! The sql standard says that there should be a space after the double dash, somebody reported it as a bug and gave the phing guys a patch, I think it came in 2.3.2?

See: http://phing.info/trac/ticket/288

—–

I’m still very happy with phing, even for some very simple tasks, it’s nice and neat.

Some of our tasks:

We have a task that puts our app in and out of maintenance mode.

We have a task to copy our dojo folder to dojo-src, then run the dojo build scripts to create a compact version for quicker downloads
config

We have a example config file with placeholders, a task then takes the config file and uses the reflexive task to set the values we need.

We fetch our code from subversion, placing it in a release folder and setting symlinks to point to the file data, similar to the way capistrano does things.

PHPDoc, PHPUnit and PHP-Codesniffer run tasks.

—–

For data we tend to only include very base data in the deltas, such as standing lists like job titles.

We’re setup ready to use a second delta set, in the event a maintenance branch needs a delta and the trunk has already created new deltas, but we haven’t done so yet. I’ve tested it and it seems to work well enough, but I wont be 100% till I’ve pushed something into our app with it.

Having the seperate changesets should work well enough for you.

/ddl/01-create-person-table.sql
/dml/01-add-admin-user.sql
/dml-dev/01-add-test-persons.sql

Your production box just doesn’t run the dml-dev folder. I like the idea too, you could really get a nice test dataset in the dml-dev folder, ready for developers to crack on with what they should be doing. We actually have a data masking program, that we run on a copy of the production database to generate test data. It seems to work pretty well, and we get realistic enough data, just with a few strange names ;)

I *will* get round to writing an updated post on phing!

have you been creating any new useful task in your build.xml file? Like an undo task? :)

Also, i wanted to know if you were still satisfied with this dbdeploy task almost a year after writing this post?

And finally, what sort of data do you handle with it? Because i’m about to introduce dbdeploy to my team, but i would like to keep DML (data) and DLL (structure) changes separated so i can have for instance, dev-only deltas, and dev+prod deltas and i’m not sure if there is a best practice for these issues. I’m thinking of using 2 separate directories which would both have a corresponding “deltaSet” (the use of this field is not well documented anywhere though). Any comment/idea would be more than welcome! ;)