mtrack: burndown and postgres

It's that time of the month... mtrack update time. Not a huge number of items to report on this time around, but it's a decently significant stepping stone--the schema management code takes us one step closer to an upgrade/deployment process.

  • If you don't explicitly include the burndown macro text in a milestone, a default burndown graph will now be displayed when the milestone summary is rendered in the roadmap section.
  • Added schema management code to handle upgrades that change the schema
  • Added preliminary postgres DB support on top of the schema management code.
  • Revised attachment processing so that the database stores a canonical copy of each attachment. This step helps to enable multiple front-end web servers to be used with the same backend pgsql DB.
  • Created a stable branch that holds the changes up to just before the PostgreSQL DB changes

HOWTO: Use the schema manager to upgrade your instance

After you have pulled the latest code, run the schema tool to bring your database instance up to date. With any upgrade where you are modifying a database, you should make sure that you have taken a backup before the upgrade is performed. 

% php bin/schema-tool.php

HOWTO: Install mtrack using PostgreSQL as the backend

mtrack does not currently have a way to migrate an existing SQLite installation to PostgreSQL.

PostgreSQL support is preliminary and not fully tested. The basics work for me in my development copy--I'm not aware of any issues at this time. Feedback is welcome!

First, create a postgres database for use with mtrack: 

% createdb -E=UTF-8 mtrack

Second, initialize your mtrack instance, specifying the DSN: 

% php bin/init.php --dsn "pgsql:dbname=mtrack;user=wez"

And you're all set.

The DSN can be any valid PDO PostgreSQL connection string.

A Note on database support

PostgreSQL support was possible to implement due to the similarities between SQLite and PostgreSQL SQL syntax. I have no plans to personally work on other databases, and will be resistant to the idea of big patches to mtrack to make it work with databases with radically different SQL syntax on the grounds that I can't test those.

I'd be looking for somone to commit to maintaining their database of preference with mtrack before I will allow non-trivial changes into the main code base.

This doesn't mean I won't consider having mtrack supporting database X; I just won't personally support database X--there will need to be a champion that is willing to commit to supporting that system for it to be part of the codebase.