Skip to content
This repository
Browse code

Fixed some typos and a more common grammar styles.

  • Loading branch information...
commit 0351896f71bb06605eb85060bd5b9f72309569b1 1 parent e93e422
Joseph Pecoraro authored May 31, 2009

Showing 1 changed file with 3 additions and 3 deletions. Show diff stats Hide diff stats

  1. 6  railties/guides/source/migrations.textile
6  railties/guides/source/migrations.textile
Source Rendered
... ...
@@ -1,10 +1,10 @@
1 1
 h2. Migrations
2 2
 
3  
-Migrations are a convenient way for you to alter your database in a structured and organised manner. You could edit fragments of SQL by hand but you would then be responsible for telling other developers that they need to go and run it. You'd also have to keep track of which changes need to be run against the production machines next time you deploy.
  3
+Migrations are a convenient way for you to alter your database in a structured and organized manner. You could edit fragments of SQL by hand but you would then be responsible for telling other developers that they need to go and run it. You'd also have to keep track of which changes need to be run against the production machines next time you deploy.
4 4
 
5 5
 Active Record tracks which migrations have already been run so all you have to do is update your source and run +rake db:migrate+. Active Record will work out which migrations should be run. It will also update your +db/schema.rb+ file to match the structure of your database.
6 6
 
7  
-Migrations also allow you to describe these transformations using Ruby. The great thing about this is that (like most of Active Record's functionality) it is database independent: you don't need to worry about the precise syntax of +CREATE TABLE+ any more that you worry about variations on +SELECT *+ (you can drop down to raw SQL for database specific features). For example you could use SQLite3 in development, but MySQL in production.
  7
+Migrations also allow you to describe these transformations using Ruby. The great thing about this is that (like most of Active Record's functionality) it is database independent: you don't need to worry about the precise syntax of +CREATE TABLE+ any more than you worry about variations on +SELECT *+ (you can drop down to raw SQL for database specific features). For example you could use SQLite3 in development, but MySQL in production.
8 8
 
9 9
 You'll learn all about migrations including:
10 10
 
@@ -538,7 +538,7 @@ There is no need (and it is error prone) to deploy a new instance of an app by r
538 538
 
539 539
 For example, this is how the test database is created: the current development database is dumped (either to +db/schema.rb+ or +db/development.sql+) and then loaded into the test database.
540 540
 
541  
-Schema files are also useful if you want a quick look at what attributes an Active Record object has. This information is not in the model's code and is frequently spread across several migrations but is all summed up in the schema file. The "annotate_models":http://agilewebdevelopment.com/plugins/annotate_models plugin, which automatically adds (and updates) comments at the top of each model summarising the schema, may also be of interest.
  541
+Schema files are also useful if you want a quick look at what attributes an Active Record object has. This information is not in the model's code and is frequently spread across several migrations but is all summed up in the schema file. The "annotate_models":http://agilewebdevelopment.com/plugins/annotate_models plugin, which automatically adds (and updates) comments at the top of each model summarizing the schema, may also be of interest.
542 542
 
543 543
 h4. Types of Schema Dumps
544 544
 

0 notes on commit 0351896

Please sign in to comment.
Something went wrong with that request. Please try again.