Hi Grar,
If you really want to call a single migration, you could do something
like:
$ ./script/console
...
>> require "#{RAILS_ROOT}/db/migrate/100_create_foos.rb"
=> ["CreateFoos"]
>> CreateFoos.down
== CreateFoos: reverting =============================
-- drop_table(:foos)
...
>> ActiveRecord::Base.connection.tables.include?('foos')
=> false
>> CreateFoos.up
== CreateFoos: migrating =============================
-- create_table(:foos)
...
>> ActiveRecord::Base.connection.tables.include?('foos')
=> true
And/or roll such calls into a runnable script and run it via runner:
$ cat ./script/migrate_foo.runnable
require "#{RAILS_ROOT}/db/migrate/100_create_foos.rb"
CreateFoos.down
CreateFoos.up
$ ./script/runner ./script/migrate_foo.runnable
...
Personally, I like to keep my migrations intact as well, one per
persistable model ob, unless I'm working on a project with a team that
doesn't. This way it's easy for devs to see exactly what's defined at
that time in the db for a given model ob, without having to weed
through all the various modifying migrations related to some model ob,
or looking for such info in the development_structure.sql if
available, or having to fire up the console or an underlying db qry
tool to see that model ob's current db schema.
For all my projects, I usually dev a runnable re-init script that
contains all of the work (that I would typically call by hand)
required to put the env in the current valid working state: run
migrations, load any init data as required for the env, perform any
post-init processing of data, run tests, etc.
Whenever a new migration is added or an existing one is modified or
init data is added/modified, I just make one call to re-init the dev
env. Note that the same holds true for pulling and re-init'ing some
version from svn/git/....
When it comes to upgrading the production env for a new release that
requires db-related changes, I dev a runnable script per prod env
upgrade that performs the necessary work to upgrade the prod env to be
in line with that particular release: run pre-upgrade tests to see if
upgrade can/should be performed, run specific migrations and/or db
schema mods as applicable, load any data and/or perform any data
updates, run post-upgrade tests, etc.
Whenever a prod env upgrade needs to be performed, I dump the prod env
db as a pre-upgrade backup, run the upgrade script to pre-test the
prod env, upgrade the prod env, and post-test the prod env, and when
all is good, dump the db again as a post-upgrade backup. (I usually
test each upgrade scripts against a similar version/state of the dev
env prior to performing the upgrade on the prod env, and once the
script's working as intended, then I just re-init the current dev
env.) Having such prod env upgrade scripts (and related db dumps)
makes it equally easy to revert back to a specific state of the prod
env as well.
Jeff
On Mar 19, 11:22 am, Grary <grary.sti...@gmail.com> wrote:
> Yes, I've certainly given the role of seed data due consideration in
> another context, but it's not relevant in the case at hand, I don't
> think. In that case at hand, the large data set I seek to include in
> my development is used for autocompletion and by business logic on the
> model side.
>
> Thanks,
>
> Grar
>
> On Mar 19, 1:50 pm, Colin Law <clan...@googlemail.com> wrote:
>
>
>
> > On 19 March 2010 16:07, Grary <grary.sti...@gmail.com> wrote:
>
> > > Hi,
>
> > > I prefer to keep one migration per model, but lately I'm adding data
> > > that's expensive to drop every time I change my models.
>
> > It is considered a bad idea to seed data using migrations, if that is
> > what you are doing. Google for rails migration seed for many
> > discussions on this issue, including on this list. Perhaps this is
> > your fundamental problem.
>
> > Colin
>
> > > How do I db:drop and db:migrate only selected tables/files? Basically,
> > > I want to ignore certain tables and migrations altogether during
> > > certain development phases.
>
> > > Thanks,
>
> > > Grar
>
> > > --
> > > 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-t...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > rubyonrails-talk+unsubscr...@googlegroups.com.
> > > For more options, visit this group
> > > athttp://groups.google.com/group/rubyonrails-talk?hl=en.
--
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-t...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
