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.
On Tue, Jul 1, 2008 at 4:23 PM, Neil [email protected]
wrote:
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.
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 D… Hi Patrick, it’s Betty, remember
me?”…
“Hello, may I speak to Patrick D… Hi Patrick, it’s Sally, remember
me?”…
“Hello, may I speak to Patrick D… 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 D., but he sounds like he was a fun guy! 
–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 D. I lived with. Patrick D.s must
have serious skillz.