Thanks Jeff. That's a lot to digest, but I will and likely try it, too. Grar
On Mar 19, 4:03 pm, Jeff Lewis <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: > > > > On 19 March 2010 16:07, Grary <[email protected]> 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 [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]. > > > > 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 [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-talk?hl=en.
