Random() bits of development musings

So here it is the first ever series. It’s been a while since I posted the introduction but the posts should be coming thick and fast now I’ve chosen my first subject, DB Schema. This is something we’ve recently implemented at work and, if I do say myself, it has been reasonably successful. In this first post I’m going to outline what I want the project to achieve.

I think it would be amiss not to have a quick scan of what’s already available. There are various implementations of this sort of functionality like Ruby on Rails migration, Phing DBDeploy Task and eZ Components DB Schema. Looking over the eZ components DB Schema documentation page shows they’ve done an extensive amount of work. Their implementation should fulfil any developers possible need. I only intend to implement a subset of what they have.

Zend Framework currently has a couple of proposals drafted but as yet no actual activity on this front. I’m hoping that the final product of this series will be acceptable as a contribution. This means that everything I go through here will be compliant with ZF’s guidelines.

My goals for this series are to provide a working implementation, the unit tests and documentation for the final submission of the proposal to the Zend Framework. As such I will be using components from the Zend Framework, specifically the DB classes and the functionality they offer. My objectives for the implementation is to provide a set of loosely coupled classes which a developer can take and mould to their specific needs.

The classes will provide a vendor neutral fluent interface to allow the developer to quickly create database schema changes which can be applied across multiple databases and servers. The problem with abstraction layers is that they generalise, so the interface needs to allow the developer to access the specific functionality easily when it’s needed. There are two further areas of requirements for this project. The first is the schema patches need to be able to downgrade the schema as well as upgrade. If there’s a major problem with your application and you have to downgrade the code, you’ll want to downgrade the database as well.

Lastly is the need to be able to handle errors gracefully. At first this seems obvious, shouldn’t all code handle errors gracefully? What I mean by this is that you don’t want to update your production server and find the database update dies half way through it’s changes. A nightmare ensues trying to figure out why the update failed, how far it got and how to fix the tables to make sure your application code keeps running. This means that the classes have to try to handle errors and undo changes where possible. There also needs to be a detailed log of the actions that were taken an succeeded, the action that failed with the reason and the steps that were taken to rectify the problem, if any. I’m not sure how successfully this can be implemented but it’s something I want to strive for if possible.

Proposal requirements:

• code
• unit tests
• documentation

A quick round up of project requirements:

• flexible architecture
• fluent interface (with code completion/hinting for IDEs)
• access to the database adapter
• flexible patch ordering system
• flexible patch syntax (PHP and SQL)
• ability to upgrade and downgrade
• error handling and reporting

That concludes the first part of this series. Hopefully I’ve outlined everything I want the final code to do and my expectations. In the next part I’ll be looking at breaking the requirements down, setting up the project structure and creating a few of the initial unit tests.