So occassionally my migrations go...uh... off the rails. One of them fails, and then I start getting errors about fields already existing, etc. Or I make some changes to a database by hand, and then need to bring the migration back in synch with the db without nuking the db contents. Sometimes I can turn the schema into a migration to accomplish this. But other times the errors continue. Is there a better way to bring a migration and existing db into synch? Thanks! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
magic_hat wrote:> So occassionally my migrations go...uh... off the rails. One of them > fails, and then I start getting errors about fields already existing, > etc. Or I make some changes to a database by hand, and then need to > bring the migration back in synch with the db without nuking the db > contents. > > Sometimes I can turn the schema into a migration to accomplish this. > But other times the errors continue. Is there a better way to bring a > migration and existing db into synch?The biggest thing is to test your migration in the development environment. That will get rid of many problems. But if for some reason your migration get''s an error in the production environment you can just comment out the part of the migration it has already done (you can tell by where the error occured) then run again. That migration has not be checked off yet it will just skip your commented section and pick up where it left off. Alternatively you can make the rest of the changes manually and then just bump the version in the schema table to make rails think you ran it. Eric --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 7/19/07, Eric Anderson <eric-ANzg6odk14w@public.gmane.org> wrote:> > magic_hat wrote: > > So occassionally my migrations go...uh... off the rails. One of them > > fails, and then I start getting errors about fields already existing, > > etc. Or I make some changes to a database by hand, and then need to > > bring the migration back in synch with the db without nuking the db > > contents. > > > > Sometimes I can turn the schema into a migration to accomplish this. > > But other times the errors continue. Is there a better way to bring a > > migration and existing db into synch? > > The biggest thing is to test your migration in the development > environment. That will get rid of many problems. But if for some reason > your migration get''s an error in the production environment you can just > comment out the part of the migration it has already done (you can tell > by where the error occured) then run again. That migration has not be > checked off yet it will just skip your commented section and pick up > where it left off. > > Alternatively you can make the rest of the changes manually and then > just bump the version in the schema table to make rails think you ran it. > > EricOr you could use a real database that supports transactional DDL. Pat --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 19-Jul-07, at 5:09 PM, Eric Anderson wrote:> > magic_hat wrote: >> So occassionally my migrations go...uh... off the rails. One of them >> fails, and then I start getting errors about fields already existing, >> etc. Or I make some changes to a database by hand, and then need to >> bring the migration back in synch with the db without nuking the db >> contents. >> >> Sometimes I can turn the schema into a migration to accomplish this. >> But other times the errors continue. Is there a better way to bring a >> migration and existing db into synch? > > The biggest thing is to test your migration in the development > environment. That will get rid of many problems. But if for some > reason > your migration get''s an error in the production environment you can > just > comment out the part of the migration it has already done (you can > tell > by where the error occured) then run again. That migration has not be > checked off yet it will just skip your commented section and pick up > where it left off. > > Alternatively you can make the rest of the changes manually and then > just bump the version in the schema table to make rails think you > ran it. > > EricI have, to date, found two bad habits cause havoc - if you don''t do these two you will have more migration smiles. 1. don''t edit by tables with your sql tool - always use migrations if you''re gonna use a system, us it - otherwise pain is your reward 2. don''t edit old migrations - you''re running the the risk of creating a migration that''s gonna break something. Keep moving forward. I''ve you''ve got a new column, then create a migration that ads the column - don''t edit the original create migration If you do the above (and test your migration) you won''t have to do any column check tricks cheers, Jodi --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
An improvement is ro run your migrations in a transaction. http://www.redhillonrails.org has a grat plugin for this (Transactional migrations) Regards Wim Jodi Showers wrote:> On 19-Jul-07, at 5:09 PM, Eric Anderson wrote: > > >> magic_hat wrote: >> >>> So occassionally my migrations go...uh... off the rails. One of them >>> fails, and then I start getting errors about fields already existing, >>> etc. Or I make some changes to a database by hand, and then need to >>> bring the migration back in synch with the db without nuking the db >>> contents. >>> >>> Sometimes I can turn the schema into a migration to accomplish this. >>> But other times the errors continue. Is there a better way to bring a >>> migration and existing db into synch? >>> >> The biggest thing is to test your migration in the development >> environment. That will get rid of many problems. But if for some >> reason >> your migration get''s an error in the production environment you can >> just >> comment out the part of the migration it has already done (you can >> tell >> by where the error occured) then run again. That migration has not be >> checked off yet it will just skip your commented section and pick up >> where it left off. >> >> Alternatively you can make the rest of the changes manually and then >> just bump the version in the schema table to make rails think you >> ran it. >> >> Eric >> > > > I have, to date, found two bad habits cause havoc - if you don''t do > these two you will have more migration smiles. > > 1. don''t edit by tables with your sql tool - always use migrations > if you''re gonna use a system, us it - otherwise pain is your reward > > 2. don''t edit old migrations - you''re running the the risk of > creating a migration that''s gonna break something. > Keep moving forward. I''ve you''ve got a new column, then create a > migration that ads the column - don''t edit the original create migration > > If you do the above (and test your migration) you won''t have to do > any column check tricks > > cheers, > Jodi > > > > >-- NEW on aXs GUARD: SSL VPN !! (contact your reseller for more info) --------------------------------------------------- aXs GUARD has completed security and anti-virus checks on this e-mail (http://www.axsguard.com) --------------------------------------------------- Able NV: ond.nr 0457.938.087 RPR Mechelen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---