Author: Sergey Chernyshev

I was struggling with DBUpgrade in projects with multiple independent components. I had to maintain the schema in main project which was quite crazy considering that projects are independent and have different timelines that had to be in sync.

So I changed DBUpgrade to OO model and added namespacing so you can have multiple schema-versioning tables in the same database and update them independently from each other.

To identify subproject and have it’s version to be kept separately, you can supply 3rd parameter when you create DBUpgrade object.

$dbupgrade = new DBUpgrade($db, $versions, 'myproject');

If you omit this parameter (makes sense for main project) then it will revert to previous behavior and use db_version table for this schema’s versioning. This way, it’s backwards compatible and provides easy migration path.

I also renamed a bunch of files so you might want to update your code, but it should be very easy as I provided a boilerplate dbupgrade.php which you can just copy to your folder and move your migrations and DB connection info over.

If you noticed, I also bundled a simple upgrade client which is already included in a boilerplate so it works for full upgrade (will run all migrations to the latest version):

[user@example myproject]$ php dbupgrade.php
Upgrading from v.0 to v.2
Upgraded to v.1
Upgraded to v.2

and single version downgrade (only downgrades to previous version):

[user@example myproject]$ php dbupgrade.php down
Downgrading from v.2 to v.1
Downgraded to v.1

in command line mode.

Full upgrade can also be executed through the web by opening very same dbupgrade.php in the browser:

http://www.example.com/dbupgrade.php

I also moved the project to Github hosting to encourage more openness and community so you can now fork it easily!

Github also supports Subversion read-only endpoints so if you’re using SVN externals to bundle DBUpgrade with your project, you can simply update your trunk URL to:

http://svn.github.com/sergeychernyshev/DBUpgrade.git

Feel free to use it as Git submodule or SVN External within your project and hope you’ll find it much easier to maintain deployment roll-outs now.