Migrating the database when switiching to a branch with a different schema

Does anyone have any suggestions on how to quickly move to and from Git branches with different database schemas? For example, my 'master' branch only has a 'users' scaffold, but my 'adding_pictures' branch has 'users' and 'pictures' scaffolding. If I'm working on the 'adding_pictures' branch and I need to change back to the 'master' branch, I'll need to drop the databases, run rake migrate, and run rake db:fixtures:load (and that's ignoring the fact that I'm running on rspec), just to get the database in a shape that's ready to handle working on the 'master' branch. Am I missing something, or is there an easier route?

Would

rake :db:schema:load

do the trick?

I use that, along with a clever idea I read at http://quotedprintable.com/2007/11/16/seed-data-in-rails, in order to load up seed data into my database. I take it one step further though, instead of the dependency:

  task :seed => :environment do

described in Jeffrey's article, I make my seed task depend on schema:load (as well as environment) with

  task :seed => [:environment, "schema:load"] do

That way, when I type

rake db:seed

I get my development database back into known good order. I also installed the "ar_fixtures" plugin (from http://topfunky.net/svn/plugins/ar_fixtures) so that I can dump my development database tables into fixtures files, and modified it slightly so that I specify the output file into which it should dump the fixture data (so that it goes into my "db/fixtures" directory instead of the default test/fixtures directory).

I'm not switching between branches (at the moment), but there's no reason that these sort of tweaks shouldn't work for you.

--wpd

Thanks Patrick (my last house mate had the same full name as you - unfortunately, he wasn't a Rails developer). I'm happy with how those suggestions work, and I've read through Jeremy's post, too. I have a couple of questions:

• How are you differentiating between fixtures which are required for the app to run in production (i.e. setting up an admin user or a 'general' category) and those that are purely used as placeholder content, like 'lorem ipsum' comments so that you can see how the comments index looks with pagination? I see those as two very different things which could easily get mixed up. I'm conjuring up a plan to have a db/fixtures/production and a db/fixtures/development folder. That way, I'll know what I will need to get the app running, and what I need just as I'm going along in development.

• Are we supposed to check the schema.rb in to the version control system? I watched the peepcode on git, and that shows the schema.rb being ignored. I just checked in the schema.rb, and the comments suggest the Rails core guys think we should keep it checked it. From what we've been discussing, it would seem advisable to do so.

Thanks Patrick (my last house mate had the same full name as you - unfortunately, he wasn't a Rails developer).

I'm still a newbie, and haven't earned my developers wings yet. I was just thrilled to see a question on the list to which I knew an answer.

I'm happy with how those suggestions work, and I've read through Jeremy's post, too. I have a couple of questions:

• How are you differentiating between fixtures which are required for the app to run in production (i.e. setting up an admin user or a 'general' category) and those that are purely used as placeholder content, like 'lorem ipsum' comments so that you can see how the comments index looks with pagination? I see those as two very different things which could easily get mixed up. I'm conjuring up a plan to have a db/fixtures/production and a db/fixtures/development folder. That way, I'll know what I will need to get the app running, and what I need just as I'm going along in development.

I haven't thought of that. Your idea sounds very workable. In my (admittedly very) simple case, I don't have any placeholder content. I have content that will will be the production content if/when I deploy my application. In my case, our current "database" is rather ungainly Excel spreadsheet. As long as I can maintain synchronization with that spreadsheet, my development data is my production data. My challenge, in my totally ignorant newbieness, is to produce something that looks and works slicker than the spreadsheet. I still have a _lot_ to learn about CSS, Javascript, and Ajax, before I'm ready to convince others that my web based database backed application is a better solution than the spreadsheet. (If it looks clunky, nobody will want to use it.)

• Are we supposed to check the schema.rb in to the version control system?

I do. I'm quite sure I've read that others strongly advocate doing so. As such, I'm quite surprised to hear that peepcode recommends not doing so.

I watched the peepcode on git, and that shows the schema.rb being ignored. I just checked in the schema.rb, and the comments suggest the Rails core guys think we should keep it checked it. From what we've been discussing, it would seem advisable to do so.

I agree.

And now, for something completely different...

Years and years ago, I lived in a house with 3 other people. At that time, dialup modems were still somewhat uncommon, (remember, this was years and years ago) though two of us used them. Consequently, we had 2 phone lines, and we only ever bothered to give out the phone number for the first one. The second one was listed in my name and would occasionally ring. The conversations all went similarly:

"Hello, may I speak to Patrick Doyle. Hi Patrick, it's Betty, remember me?"... "Hello, may I speak to Patrick Doyle. Hi Patrick, it's Sally, remember me?"... "Hello, may I speak to Patrick Doyle. Hi Patrick, it's Susan, remember me?"...

or, my personal favorite,

"Hi Patrick, it's Peggy. Joanne and Laura and Jeanne and Carol and I are all going out to dinner to wish Allison a bon voyage. We were wondering if you wanted to join us".

I never met that Patrick Doyle, but he sounds like he was a fun guy! :slight_smile:

--wpd

I started back in Feb, so I'm relatively new to Rails too. You've been a great help so far.

The schema.rb is now in the repo. However, I've found that rake db:schema:load doesn't quite hit the criteria for this, it only makes sure that the schema has what is required, it doesn't remove anything that isn't. That could become confusing. db:drop may be the best choice.

I like the idea of keeping a folder for development & production fixtures, but for the sake of simplicity, it could be better to use the rake db:fixtures:load task in conjunction with a tests/fixtures folder for the development fixtures, rather than having a fixtures/ development & production divide elsewhere. I'm only using them to test how the application looks, so it would make sense.

That sounds like the Patrick Doyle I lived with. Patrick Doyles must have serious skillz.