This would be a good last minute add before 1.0. It'd be helpful to have a simple, database-backed migration system that you can write up/down functions with. For example:
In the upgrade, you write the changes to move to, and in the downgrade, the changes you want to roll back. To run, just have the version pinned in node.app() like this:
The above would allow us to support multiple databases and track which migration we should be at. Each respective database would get its own migrations collection/table that tells us this information. If it doesn't exist, we'd assume that whatever was past is both the first/current migration.
On startup of the app, we'd first handle any migration.define() calls and then check the migrations collection/table to see if we're already at the specified version. If not, we'd run the corresponding up function.
When "rolling back" to an older version, we'd need to take the passed version and diff against others in the database by their migratedAt/migrated_at field and decide which downgrade functions to call on the versions in the diff.
This would be a good last minute add before 1.0. It'd be helpful to have a simple, database-backed migration system that you can write up/down functions with. For example:
In the
upgrade
, you write the changes to move to, and in thedowngrade
, the changes you want to roll back. To run, just have the version pinned innode.app()
like this:The above would allow us to support multiple databases and track which migration we should be at. Each respective database would get its own
migrations
collection/table that tells us this information. If it doesn't exist, we'd assume that whatever was past is both the first/current migration.On startup of the app, we'd first handle any
migration.define()
calls and then check themigrations
collection/table to see if we're already at the specified version. If not, we'd run the corresponding up function.When "rolling back" to an older version, we'd need to take the passed version and diff against others in the database by their
migratedAt/migrated_at
field and decide whichdowngrade
functions to call on the versions in the diff.