Rails core - Apr 2009 - a home for seed data, other than migrations

I''ve been thinking about this for a while, there''s plenty of
people
who say data manipulation doesn''t belong in migrations, though I  
haven''t heard a lot of evidence as to why.  This topic popped up again
on "Chad Fowler''s 20 Rails Development No-No''s",
#15:  http://www.chadfowler.com/2009/4/1/20-rails-development-no-no-s
  , where a commenter says " If it’s created in a migration, it’s lost  
when you clone_structure_to_test, so it’s not available for your tests"

I think the primary reason developers do this is because there isn''t a
good alternative.  If I want to roll out a new look-up table to a  
server, a migration is already in the right place at the right time  
when it''s creating the table.  Why make more work for myself and  
maintain it manually?

My proposed solution is to formally provide a way in Rails to handle  
table seed data:
- create a db/seed_data/ or db/table_init/ folder.  I kinda like the  
latter.
- on table create or after clone_structure, run the appropriate ruby  
scripts in db/table_init/

Advantages over seed data in migrations:
- can be easily maintained and re-run at any time
- stored in a central place instead of spread across many migrations
- tests can use this to populate look-up tables after cloning dev  
structure

Questions:
- Are there any other reasons migrations are bad for seed data?

Feedback is appreciated, I''m more than willing to code up the solution.

Steven Soroka


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

On Apr 10, 1:53 pm, Steven Soroka <ssorok...@gmail.com>
wrote:
> I think the primary reason developers do this is because there
isn''t a  
> good alternative.
I think there are a number of reasonably good techniques available.
The top two results for this Google search are probably a good
starting point:

http://www.google.com/search?q=rails+seed+data

Personally, I''m happy just creating my own "rake db:populate"
task and
invoking that when necessary.

Still, I think there''s room for some convention to emerge here. I just
don''t we''re at the "one really popular plugin or
technique emerges as
the winner" part.

Maybe a good way to approach the problem would be to create a plugin
or technique and to try and promote it as the best solution. Perhaps
then, if appropriate, someone on Rails Core would see fit to pull it
into Rails proper. If not, you could at least have a popular plugin on
your hands :)

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