Rails - Jul 2008 - 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?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 Jul 1, 6:20 pm, "Patrick Doyle"
<wpds...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Would
>
> rake :db:schema:load
>
> do the trick?
>
> I use that, along with a clever idea I read
athttp://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
(fromhttp://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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Tue, Jul 1, 2008 at 4:23 PM, Neil
<NeilCauldwell-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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.
>  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! :-)

--wpd

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On Jul 2, 12:59 am, "Patrick Doyle"
<wpds...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Tue, Jul 1, 2008 at 4:23 PM, Neil
<NeilCauldw...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> 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.
>
> >  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! :-)
>
> --wpd
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---