I''m just getting into Rails and it seems very cool so far. However I''m having trouble understanding why Migrations are so important. For past projects I''ve always used SQL comparison tools to record schema changes, and later play them back when it''s time to install a fresh DB. It''s fast, simple and it works. On the other hand With Migrations...to me it just seems like one more thing I have to write and one more thing that can go wrong. What are some good reasons for me to use Migrations versus SQL scripts? -- 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-/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 -~----------~----~----~----~------~----~------~--~---
> What are some good reasons for me to use Migrations versus SQL scripts?1) SQL scripts can''t massage the existing data using domain logic to jive with the new schema. 2) SQL scripts don''t usually have easy ways to back out of a change (migrate down). 3) SQL scripts don''t maintain a schema version automatically, so teams have to manually deal with when to run what and how. 4) SQL scripts are bound to 1 database, so they''re not portable. And they make it easy to introduce proprietary constructs, so the entire schema is rendered unportable. 5) SQL scripts are written in SQL, not Ruby. David Heinemeier Hansson --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
ok..enough said. Whats the best way to handle scheme update slike adding/droping relation ships and indexes? Embed SQL into the migration? DHH wrote:>> What are some good reasons for me to use Migrations versus SQL scripts? > > 1) SQL scripts can''t massage the existing data using domain logic to > jive with the new schema. > 2) SQL scripts don''t usually have easy ways to back out of a change > (migrate down). > 3) SQL scripts don''t maintain a schema version automatically, so teams > have to manually deal with when to run what and how. > 4) SQL scripts are bound to 1 database, so they''re not portable. And > they make it easy to introduce proprietary constructs, so the entire > schema is rendered unportable. > 5) SQL scripts are written in SQL, not Ruby. > > > David Heinemeier Hansson-- 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-/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 -~----------~----~----~----~------~----~------~--~---
Brandon, One of the things I really like about fixtures is (as DHH said) you can revert back down to whatever version you like, make a change to the migration (for example, add a field you didn't know you needed), then revert back up to the current version. Then, I use fixtures to load all my sample data into my DEV DB and I am back in business...about 20 seconds from start to finish. I can't speak to how/if you can do that with SQL scripts, but I know it's a nice feature of migrations. It's also all done independent of the particular database, which is nice when you work with more than one (MySQL/PostgreSQL/etc.) Nathan -----Original Message----- From: rubyonrails-talk@googlegroups.com [mailto:rubyonrails-talk@googlegroups.com]On Behalf Of Brandon Casci Sent: Friday, September 08, 2006 11:50 AM To: rubyonrails-talk@googlegroups.com Subject: [Rails] Migrations Vs SQL compare tools I'm just getting into Rails and it seems very cool so far. However I'm having trouble understanding why Migrations are so important. For past projects I've always used SQL comparison tools to record schema changes, and later play them back when it's time to install a fresh DB. It's fast, simple and it works. On the other hand With Migrations...to me it just seems like one more thing I have to write and one more thing that can go wrong. What are some good reasons for me to use Migrations versus SQL scripts? -- 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@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
You may want to checkout Agile Web Development 2nd edition which contains a chapter on migrations. Or the API. Relationships are done through the model / class files. And there are also some interesting plugin''s for associations as well. Stuart On 9/8/06, Brandon Casci <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > ok..enough said. > > Whats the best way to handle scheme update slike adding/droping relation > ships and indexes? Embed SQL into the migration? > > DHH wrote: > >> What are some good reasons for me to use Migrations versus SQL scripts? > > > > 1) SQL scripts can''t massage the existing data using domain logic to > > jive with the new schema. > > 2) SQL scripts don''t usually have easy ways to back out of a change > > (migrate down). > > 3) SQL scripts don''t maintain a schema version automatically, so teams > > have to manually deal with when to run what and how. > > 4) SQL scripts are bound to 1 database, so they''re not portable. And > > they make it easy to introduce proprietary constructs, so the entire > > schema is rendered unportable. > > 5) SQL scripts are written in SQL, not Ruby. > > > > > > David Heinemeier Hansson > > > -- > 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-/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 -~----------~----~----~----~------~----~------~--~---
On 9/8/06, Brandon Casci <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > ok..enough said. > > Whats the best way to handle scheme update slike adding/droping relation > ships and indexes? Embed SQL into the migration? > >Yes. Use the execute command for SQL not covered by the migrate syntax, like this example: execute "ALTER TABLE items ADD COLUMN cost_unit DECIMAL(5,2) NOT NULL DEFAULT 0" For relationships, you might want to take a look at the foreign_key_migrations plugin, which will automatically set up the relationships in your schema based on your field names. Has worked well for me and a nice shortcut. -- "Impossible is nothing." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Yup....I just got the 2nd edition an hour ago. It has a lot more than the 1st addition. -- 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-/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 -~----------~----~----~----~------~----~------~--~---
On 08/09/06, Brandon Casci <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > ok..enough said. > > Whats the best way to handle scheme update slike adding/droping relation > ships and indexes? Embed SQL into the migration?You can add_column, create_index etc. For stuff like adding triggers you use execute("some sql"); -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
johnson_d-j9pdmedNgrk@public.gmane.org
2006-Sep-08 23:10 UTC
Re: Migrations Vs SQL compare tools
Brandon Casci wrote:> I''m just getting into Rails and it seems very cool so far. However I''m > having trouble understanding why Migrations are so important. > > For past projects I''ve always used SQL comparison tools to record schema > changes, and later play them back when it''s time to install a fresh DB. > It''s fast, simple and it works. > > On the other hand With Migrations...to me it just seems like one more > thing I have to write and one more thing that can go wrong. > > What are some good reasons for me to use Migrations versus SQL scripts? > > > -- > Posted via http://www.ruby-forum.com/.Try doing that with an 8 TB database, with a maximum allowed downtime of 1 hour, when an entire team''s salaries are measured in minutes of downtime. A streaming migration that maxes out both the originating and target IO systems can just barely do it. Unload and reload via SQL scripts takes at least 3 times as long. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
DHH wrote:>> What are some good reasons for me to use Migrations versus SQL scripts? > > 1) SQL scripts can''t massage the existing data using domain logic to > jive with the new schema. > 2) SQL scripts don''t usually have easy ways to back out of a change > (migrate down). > 3) SQL scripts don''t maintain a schema version automatically, so teams > have to manually deal with when to run what and how. > 4) SQL scripts are bound to 1 database, so they''re not portable. And > they make it easy to introduce proprietary constructs, so the entire > schema is rendered unportable. > 5) SQL scripts are written in SQL, not Ruby.Thanks for such a clear and concise answer - I had similar concerns to the OP. I''m interested to know whether/how migrations can be used in a situation where branches exist in the repository: a) where released code and schema are being maintained on a release branch, while development continues on the trunk b) where a branch is being used to work on a variant, which may (if successful) end up being merged into the trunk again. regards Justin Forder --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks to everyone for all the answers. I''m digging the migrations now. -- 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-/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 -~----------~----~----~----~------~----~------~--~---