Comments on: Automatically Creating, Loading, and Migrating your Database (with magic!)

By: Josh Nichols

Josh Nichols — Fri, 02 May 2008 19:20:40 +0000

This seems like it’d be extremely useful… in development.

For production, I think capistrano can nicely handle creating/migrating the database.

By: links for 2008-04-24 | Libin Pan

links for 2008-04-24 | Libin Pan — Thu, 24 Apr 2008 06:40:13 +0000

[...] almost effortless Â» Automatically Creating, Loading, and Migrating your Database (with magic!) Automatically Creating, Loading, and Migrating your Database (with magic!) (tags: activerecord database rails rubyonrails migrations rake ruby) [...]

By: David Mathers

David Mathers — Sun, 13 Apr 2008 22:36:54 +0000

With MySQL you can use:

http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock

By: Al Brown

Al Brown — Sat, 12 Apr 2008 00:14:20 +0000

this seems dangerous

Wouldn’t it be better if the code notified you (by emailing you a report or a URL for it) as to what changes it needs to make and give you the option of approving?

In the mean time, your app can make people wait until the db version is correct.

Starting your app could also display a message, but with everything automated, you won’t see it.

I think its best that you avoid depending on this mechanism though. Your best beat is to establish robust processes that check the db version and do the appropriate thing before restarting your app. Yes, the above would be cooler of course, but looking goofy to your users just once because of it will wipe out any coolness upgrade it buys you.

By: Malcontent

Malcontent — Fri, 11 Apr 2008 22:53:47 +0000

Rake keeps the latest version in the database, why not do this…

check if the database exists, if not create it and migreate.

If the database exists see if the migration tables are there. If not migrate.

Check latest version from the database and migrate if needed.

Come to think of it why not migrate if the database exists? What’s the harm in running the migration?

By: Trevor

Trevor — Fri, 11 Apr 2008 16:58:24 +0000

Michael, that’s interesting. Maybe wrapping the entire thing in a transaction wouldn’t be a bad idea. I don’t see how it could hurt…

By: Michael Buckbee

Michael Buckbee — Fri, 11 Apr 2008 16:56:38 +0000

You could wrap the SQL in a transaction so that only the first mongrel (or whatever you happen to be using) got to it that it would already be taken care of.

Even without that, you’d still _probably_ be ok as the subsequent migrations would fail as soon as they hit something that already existed (like trying to add a column that was already there).

By: Rodrigo Urubata

Rodrigo Urubata — Fri, 11 Apr 2008 16:24:09 +0000

there is no need to change it for timed migrations because the format used grants a higer number every time :D

By: Rodrigo Urubata

Rodrigo Urubata — Fri, 11 Apr 2008 16:22:59 +0000

Great idea :D
I liked this initializer :D

By: Eric

Eric — Fri, 11 Apr 2008 15:15:50 +0000

Might have to change the regex if you’re using UTC migrations? Maybe go with a time parse or something…

http://ryandaigle.com/articles/2008/4/2/what-s-new-in-edge-rails-utc-based-migration-versioning

Thanks for the Rake trick, btw!

By: Trevor

Trevor — Fri, 11 Apr 2008 15:15:34 +0000

I don’t know, actually – that’s an interesting question. Maybe there’s a way to lock the entire database or app so that no other requests would be processed at that time?

By: Adam

Adam — Fri, 11 Apr 2008 12:27:06 +0000

Love the idea but potentially couldn’t you get a race condition with multiple mongrels all trying to migrate the app at the same time?

Don’t know the internals of migrate tasks well enough to say for sure.