If we kept the integrity of migrations and moved to create something
like SeedData or an implementation of Scenarios, then we can still
keep the state that you want. We'd just have the normal migration
tasks and then tasks for seeding the data and a task for migrating and
then seeding.
IMO, I'd love to see a seed system that mimics migrations a bit and
keeps the standard AR syntax that we are used to: Person.create(...).
Perhaps something like
class SeedPeople < ActiveRecord::SeedData
def self.up
create_data :people do |p|
p.create(:name => "Robert", :password => "secret")
p.create(:name => "John", :password => "supersecret")
end
end
end
I find that the above syntax feels comfortable to me - what do other
people think of the above? John Long has a lot of this already done.
Are there issues for having a simple rake task for setting up just the
test db or even just the production db (without loading any data)?
e.g. rake db:create:test, rake db:create:production - Perhaps I'm just
not seeing the reason why these aren't nice conveniences?
On Dec 1, 11:04 am, Mike Mangino <[EMAIL PROTECTED]>
wrote:
> [snip]
>
> > Again, I think this is a mistake and it was certainly not what
> > migrations were designed for. They lead to all the pains and problems
> > you're describing with migrations.
>
> > I fully realize that people are misusing migrations in this way
> > because they were missing a seed system and just grabbed something
> > that had the same vague outline. But I think the problem then is to
> > consider how to best do seeding. Not to twist migrations into a seed
> > system.
>
> I'm one of the people misusing migrations in this way, and a seed
> system could fulfill part of the problem, but not all of it.
>
> I often use migrations for creating data that needs to be present in
> every environment. For example, a new account in an accounting table.
> I want to add that to an existing production application without
> reloading all of the data. By including it in a migration, I'm sure
> that it will exist in the database of every developer, our integration
> environment, and finally production. It keeps me from having to track
> down data bugs.
>
> Of course, the fact that I also have to encode that data into my
> fixtures isn't very DRY. I'd love to have some way of specifying the
> data only once, I just don't have any brilliant ideas about how to do
> it.
>
> [snip]
>
> Mike Manginohttp://www.elevatedrails.com
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
