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. 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Grary 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.So don''t do that. You''ve chosen to fight a (very) hard battle if that''s the manner in which you are trying to use migrations. Down the road, when you want to add a column to a table that has 100,000 rows of data, you''re going through a backup and restore for that table just so you can have a single migration file per table??? If it really is just a preference, as opposed to a hard-driven requirement, then embrace the multiple migrations convention.> > 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. >The weasely approach would be to leave all the migration files in place, and edit the contents of the migration files before you do any migrations, up or down. If you don''t want to perform a step, comment out all the business logic inside that migration file, leaving just a self.up (or self.down) that does nothing. Sounds like a royal PITA to me. -- Posted via http://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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
OK. Also, I was just thinking: if I create models and then, without a migration, create corresponding tables, I have sidestepped the problem, such as it is. Anyway, I''ve registered your skepticism. Thanks, Grar On Mar 19, 12:40 pm, Ar Chron <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Grary 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. > > So don''t do that. You''ve chosen to fight a (very) hard battle if that''s > the manner in which you are trying to use migrations. > > Down the road, when you want to add a column to a table that has 100,000 > rows of data, you''re going through a backup and restore for that table > just so you can have a single migration file per table??? > > If it really is just a preference, as opposed to a hard-driven > requirement, then embrace the multiple migrations convention. > > > > > 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. > > The weasely approach would be to leave all the migration files in place, > and edit the contents of the migration files before you do any > migrations, up or down. If you don''t want to perform a step, comment > out all the business logic inside that migration file, leaving just a > self.up (or self.down) that does nothing. Sounds like a royal PITA to > me. > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I''ve registered your skepticism. Yes, I can''t see that the benefit of satisfying my preference here outweighs the burden. That said, I still think it''s a drag to sift through multiple migration files. Thanks, Grar On Mar 19, 12:40 pm, Ar Chron <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Grary 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. > > So don''t do that. You''ve chosen to fight a (very) hard battle if that''s > the manner in which you are trying to use migrations. > > Down the road, when you want to add a column to a table that has 100,000 > rows of data, you''re going through a backup and restore for that table > just so you can have a single migration file per table??? > > If it really is just a preference, as opposed to a hard-driven > requirement, then embrace the multiple migrations convention. > > > > > 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. > > The weasely approach would be to leave all the migration files in place, > and edit the contents of the migration files before you do any > migrations, up or down. If you don''t want to perform a step, comment > out all the business logic inside that migration file, leaving just a > self.up (or self.down) that does nothing. Sounds like a royal PITA to > me. > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 19 March 2010 16:07, Grary <grary.stimon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at http://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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 19 March 2010 16:07, Grary <grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > > > > > On 19 March 2010 16:07, Grary <grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-talk-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm. > > > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > > 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 <jeff.bu...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > > > > On 19 March 2010 16:07, Grary <grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-talk@googlegroups.com. > > > > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > > > 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> I prefer to keep one migration per modelIt''s a bad an unmaintainable idea. I did that when I was a beginner in RoR. Simply create migrations to add/remove columns to existing tables. When you have too many migration files, simply remove them. The whole schema is saved in schema.rb -- Posted via http://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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
It''s the same basic strategy I''ve been using successfully for the past 15+yrs dev''ing and maintaining web apps, using various mvc frameworks, langs, etc. Don''t follow it if you don''t want, but it''s one that''s worked well for me, based on real-world experience, and saved me a lot of time/headaches. Jeff On Mar 19, 4:38 pm, Fernando Perez <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> > I prefer to keep one migration per model > > It''s a bad an unmaintainable idea. I did that when I was a beginner in > RoR. > > Simply create migrations to add/remove columns to existing tables. When > you have too many migration files, simply remove them. The whole schema > is saved in schema.rb > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fernando, When you say... "When you have too many migration files, simply remove them." ...I think this means that you refer to the schema as the one source of summary information and that migration files are not informative except when a developer wants to revert to an earlier stage via ''redo'' or ''version''. Grar On Mar 19, 7:38 pm, Fernando Perez <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> > I prefer to keep one migration per model > > It''s a bad an unmaintainable idea. I did that when I was a beginner in > RoR. > > Simply create migrations to add/remove columns to existing tables. When > you have too many migration files, simply remove them. The whole schema > is saved in schema.rb > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.