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.
Jason S. (Guest)
on 2006-05-27 01: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?
unknown (Guest)
on 2006-05-27 03: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
Jón B. (Guest)
on 2006-05-27 03:18
(Received via mailing list)
On 5/26/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> 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
>


--
Curtis S. (Guest)
on 2006-05-27 03:43
(Received via mailing list)
On 5/26/06, Jason S. <removed_email_address@domain.invalid> 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
Jason S. (Guest)
on 2006-05-27 06: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!
Curtis S. (Guest)
on 2006-05-27 19:40
(Received via mailing list)
Jason S. 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
Ezra Z. (Guest)
on 2006-05-27 21:34
(Received via mailing list)
On May 27, 2006, at 8:39 AM, Curtis S. 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
> removed_email_address@domain.invalid
> 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
Jason S. (Guest)
on 2006-05-27 22: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.