Hi Josh / List
Did you ever get anywhere with this ?
I have an existing db and I want to utilise migrations. I ignored them
initially as I couldn''t (and still can''t) find a way to dump
the
existing DATA into the schema.rb ?
How have others approached this ? I guess i can dump all existing data
to yaml or something (links below are broken) but I really wanted to
keep the data AND the defintions close together in the migrations
files as they are dependent.
It seems like such an obvious oversight that I am sure I am missing
something !
Any thoughts out there ?
Cheers
Matt
On Mar 30, 6:49 am, Joshua Muheim
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:> Hi all
>
> In my migrations I often like to create some basic modeldatathat will
> be needed in the application (e.g. a list of common countries).
>
> Till now I hard-coded them directly into the migration scripts:
>
> Country.create!(...)
>
> This is not very dynamic - what have fixtures been invented for?!
>
> Then I found the rake db:bootstrap task
fromhttp://www.railsweenie.com/forums/2/topics/778which
>
> 1) Re-creates the whole schema by running all migrations using :force =>
> true (as far as I see it).
> 2) Loads all fixture files in db/bootstrap into the database (e.g.
> countries.yml).
>
> This is quite cool, but it does only allow me to migrate to the latest
> migration schema, so I''d like to go some steps further.
> What I want is a fixtures-file-schema based on migration numbers, not on
> model names. So 001_add_some_basic_countries.yml will be loaded after
> the migration 001_xxx.rb is run. This would also allow to migrate back
> and forth to a specific state, not only to the latest schema version
> what rake db:bootstrap does. It should be possible, too, to create more
> than one fixture file per migration number, e.g.
> 002_add_some_basic_smurfs and 002_add_some_more_countries which both
> should be run after migration 002 was executed.
>
> Even better would be a directory structure that allows to create
> specific fixtures for each environment:
>
> db/migration/fixtures/development/001_some_test_countries.rb
> db/migration/fixtures/development/002_some_smurfs_that_dont_really_exist.rb
> db/migration/fixtures/development/002_some_more_countries.rb
> db/migration/fixtures/production/001_basically_needed_countries.rb
> db/migration/fixtures/production/002_really_existing_smurfs.rb
>
> So in the development database I maybe can have some test users (or
> smurfs ;-) ) with which I can test my features etc. But in production
> mode these users would be superflously, so there I would only add a God
> Administrator smurf for example.
>
> I''d like to enhance the rake db:migrate task so it fits my need.
Anybody
> sees problems with theexistingsense of how to use migrations or what
> migrations are really meant for? Is this a good idea, generally? If so,
> I will try to implement this behavior and release it as a plugin in some
> time... :-)
>
> Thanks for your opinion and constructive feedback, further suggestions
> are welcome!
> Josh
>
> --
> Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---