mtrack: burndown and postgres
Posted on 06 Oct 2010

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 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.