Forum: Ruby on Rails migration with required data

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E68d4935996d7f13cdb33ac6dc50acb7?d=identicon&s=25 Jason Sallis (jsallis)
on 2006-05-26 23:53
I'm working on a bugtracker application in rails.  I have a Bug model
and I want to add a Priority to the mix.  A Bug can have one priority.
I generate a Priority model, modify my Bug model with a belongs_to
:priority and create my migration like so:

class CreatePriorities < ActiveRecord::Migration
  def self.up
    create_table :priorities do |t|
      t.column :name, :string, :limit => 25, :null => false
    end

    add_column :bugs, :priority_id, :integer, { :null => false, :default
=> 1 }
  end

  def self.down
    remove_column :bugs, :priority_id
    drop_table :priorities
  end
end

My question is how to handle getting data into the Priorities table
during the migration.  When I call add_column, I update all Bug records
to have a default Priority_ID of 1, which works as long as I then insert
the Priority values manually into the Priority table before testing the
app, but I'd like a more seamless solution.  I need all Bug records to
have a VALID Priority and the Priorities table to be populated when the
migration is complete.

How do others handle this situation?
D5145c421cd25af6fa577c15219add90?d=identicon&s=25 unknown (Guest)
on 2006-05-27 01:08
(Received via mailing list)
Migrations aren't for populating for testing. That's what fixtures are
for (I assume that by testing, you mean unit tests, and not just
running it in dev mode and looking at it). Use migrations to populate
the priorities table (as that's a fairly static part of your model, I
assume), and put some example records in the bugs table using
fixtures. You can get it to put a random number in (between 1 and
however many priorities you have) by adding ERb into fixtures.yml.
That way, adding more than one record is just a case of copy and
paste.
Hope this helps,
-Nathan
30ee518e6fdc5b07e060775b5a542bdb?d=identicon&s=25 Jón Borgþórsson (jongretar)
on 2006-05-27 01:18
(Received via mailing list)
On 5/26/06, njmacinnes@gmail.com <njmacinnes@gmail.com> wrote:
> -Nathan
I thinks he is actually asking about manipulating data that already
exists.

> >       t.column :name, :string, :limit => 25, :null => false
> > end
> >
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-05-27 01:43
(Received via mailing list)
On 5/26/06, Jason Sallis <jsallis@gmail.com> wrote:

> My question is how to handle getting data into the Priorities table
> during the migration.  When I call add_column, I update all Bug records
> to have a default Priority_ID of 1, which works as long as I then insert
> the Priority values manually into the Priority table before testing the
> app, but I'd like a more seamless solution.  I need all Bug records to
> have a VALID Priority and the Priorities table to be populated when the
> migration is complete.

Well, keep in mind that a Migration is Ruby.  It also runs in your
Rails environ and has access to all your Models.

def self.up
  ...
  Priority.create(:name => 'Default')
  Priority.create(:name => 'Low')
  Priority.create(:name => 'Midnight Oil')
end


-Curtis
E68d4935996d7f13cdb33ac6dc50acb7?d=identicon&s=25 Jason Sallis (jsallis)
on 2006-05-27 04:21
Nathan:

I see where you're coming from, but I'm not trying to populate the data
for testing.  My end goal was to pre-populate the priorities table with
initial values and let the user later administer the tables and
add/remove/change the values.  So, adding the original values right in
the migration is my best bet, using Curtis' solution.

Curtis:

I'm a little embarrassed that I didn't think of your simple solution!
Sometimes I forget that all the code is just plain Ruby and that I have
full access to my models!

Anyway, thanks for the input all.  Definitely still tons to learn and
figuring out more every day!
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-05-27 17:40
(Received via mailing list)
Jason Sallis wrote:
> I'm a little embarrassed that I didn't think of your simple solution!
> Sometimes I forget that all the code is just plain Ruby and that I have
> full access to my models!
>
Meh.  No need to be embarrassed.  :)  I forget too...  In fact more
frequently than I would like to admit.  But rediscovering is part of
what makes Ruby/Rails so damn fun!  heehee...  And for the record, I'm
not opposed to dumping some "testing" data into a Migration.  Not
standard testing data to run *during* tests, but development data...  To
me it's silly to blow away a db (or even have the new guy migrate) and
have to repopulate data by hand...  This is Rails, it's suppose to be
fast.  What is a better way to reset your database to a well-known state
than:

rake migrate version=0
rake migrate

You can always modify the data migrations later, or even utilize some
conditional code to ensure only portions happen during production (code
tables and other necessary data...you can leave your sesame street and
hollywood actor data out).  While you're at it (during your
"authentication" migration), you might as well drop your default "admin"
user into it...  When you're creating code tables, you might as well
populate them (and that will probably even be defaults in production
code).  You may as well have a few customers in the system (wrapped in
conditional code so it only gets created in the development environ).  I
hear Charlie Sheen just LOVES to exist in development applications; Big
Bird is of the same attitude.  Make it easy...love the actors...give
them a job...

-Curtis
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-05-27 19:34
(Received via mailing list)
On May 27, 2006, at 8:39 AM, Curtis Spendlove wrote:

> development data...  To me it's silly to blow away a db (or even
> your sesame street and hollywood actor data out).  While you're at
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails


Guys-

	If you are planning to use models in your migrations there are a few
things to be careful with that can be quite surprising. See this link
for more details:

http://toolmantim.com/article/2006/2/23/migrating_...


Cheers-
-Ezra
E68d4935996d7f13cdb33ac6dc50acb7?d=identicon&s=25 Jason Sallis (jsallis)
on 2006-05-27 20:19
Thx for the link Ezra.  That looks to be a good option for avoiding the
issues that changing Models can cause.
This topic is locked and can not be replied to.