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?
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
On 5/26/06, [email protected] [email protected] 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
–
On 5/26/06, Jason S. [email protected] 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
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!
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
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
[email protected]
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_with_models
Cheers-
-Ezra
Thx for the link Ezra. That looks to be a good option for avoiding the
issues that changing Models can cause.