Opened 14 years ago

Last modified 14 years ago

#32 closed defect (FIXED)

Need a way to do schema migration on the database

Reported by: Christopher Allan Webber Owned by: Juan José González
Priority: minor Milestone:
Component: Keywords:
Cc: Parent Tickets:

Description

Over time our database format will change, and it'll be important
to be able to update peoples' existing databases. We need both a
way to specify migrations and to be able to run them.

`http://namlook.github.com/mongokit/migration.html <http://namlook.github.com/mongokit/migration.html>`_
contains some info on this.

As far as where the revision info is stored, maybe that could be
kept in something like

::

    settings_document = db['app_settings']['mediagoblin']
    settings_document['db_revision'] = 'some_identifier'

but I'm not sure. I've been thinking that maybe we'll need to store
some user settings in the database eventually once we get some sort
of admin interface around. Maybe this is the first thing to start
storing.



Change History (7)

comment:1 by Juan José González, 14 years ago

We can use the approach of lazy migration on the article. In order
to make work a different version in a specific database we can mark
migration function with a number of version. If the software is
that version or greater the function should be executed.

I think it could be done just writting the version of the software
in some config file and some DocumentMigration models.



comment:2 by Christopher Allan Webber, 14 years ago

Owner: set to Juan José González

comment:2 by Christopher Allan Webber, 14 years ago

We could store the current version of the migrations in a global
variable in models.py maybe? But storing the user's current version
of the software in a config file might be iffy, esp since most
users run the mediagoblin.ini version in the toplevel of the
application which for git's sake shouldn't change.

Thanks for jumping on this Juan, assigned to you!



comment:3 by Christopher Allan Webber, 14 years ago

In working on
`http://bugs.foocorp.net/issues/340 <http://bugs.foocorp.net/issues/340>`_
I've implemented quite a bit of this. Yeah, using mongokit's
migration stuff, which seems to work fine.



comment:4 by Christopher Allan Webber, 14 years ago

So now we have migrations but not much documentation on how they
work, but here's the basics:


-  lazy migrations should happen automatically, but we have none
   currently
-  bulk migrations have to be run manually, like so:

   ./bin/gmg migrate


So we should document this properly in the docs, both that in
general when people do a git pull that they should do ./bin/gmg
migrate to be sure but also how to write migrations (though I guess
we can just reference the mongokit docs)



comment:5 by Christopher Allan Webber, 14 years ago

Status: NewClosed
Ok, updated the docs slightly telling people to migrate every time
they run buildout. Pretty happy with this, closing this ticket!



comment:6 by Will Kahn-Greene, 13 years ago

The original url for this bug was http://bugs.foocorp.net/issues/299 .

Note: See TracTickets for help on using tickets.