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?
--
Posted via http://www.ruby-forum.com/.
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 26/05/06, Jason Sallis <jsallis@gmail.com> wrote:> 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? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 5/26/06, njmacinnes@gmail.com <njmacinnes@gmail.com> wrote:> 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, > -NathanI thinks he is actually asking about manipulating data that already exists.> > On 26/05/06, Jason Sallis <jsallis@gmail.com> wrote: > > 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? > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/
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
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! -- Posted via http://www.ruby-forum.com/.
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
On May 27, 2006, at 8:39 AM, Curtis Spendlove wrote:> 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 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsGuys- 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