ActiveRecord -> Active Record

railties/doc/guides/migrations/anatomy_of_a_migration.txt

@@ -20,12 +20,12 @@ class CreateProducts < ActiveRecord::Migration
 end
 ------------------------
 
-This migration adds a table called products with a string column called `name` and a text column called `description`. A primary key column called `id` will also be added, however since this is the default we do not need to ask for this. The timestamp columns `created_at` and `updated_at` which ActiveRecord populates automatically will also be added. Reversing this migration is as simple as dropping the table.
+This migration adds a table called products with a string column called `name` and a text column called `description`. A primary key column called `id` will also be added, however since this is the default we do not need to ask for this. The timestamp columns `created_at` and `updated_at` which Active Record populates automatically will also be added. Reversing this migration is as simple as dropping the table.
 
 === Migrations are classes
 A migration is a subclass of `ActiveRecord::Migration` that implements two class methods: +up+ (perform the required transformations) and +down+ (revert them).
 
-ActiveRecord provides methods that perform common data definition tasks in a database independent way (you'll read about them in detail later):
+Active Record provides methods that perform common data definition tasks in a database independent way (you'll read about them in detail later):
 
 * `create_table`
 * `change_table`

railties/doc/guides/migrations/creating_a_migration.txt

@@ -25,7 +25,7 @@ end
 -----------------------
 
 You can append as many column name/type pairs as you want. By default `t.timestamps` (which creates the `updated_at` and `created_at` columns that
-are automatically populated by ActiveRecord are also created) will be added for you.
+are automatically populated by Active Record are also created) will be added for you.
 
 === Creating a standalone migration ===
 If you are creating migrations for other purposes (for example to add a column to an existing table) then you can use the migration generator:

railties/doc/guides/migrations/migrations.txt

@@ -1,14 +1,14 @@
 Migrations
 ==========
 
-Migrations are a convenient way for you to alter your database in a structured and organised manner. ActiveRecord takes care of working out which migrations have already been run so you can just update your source and run the migrations, leaving ActiveRecord to work out the details.
+Migrations are a convenient way for you to alter your database in a structured and organised manner. Active Record takes care of working out which migrations have already been run so you can just update your source and run the migrations, leaving Active Record to work out the details.
 
 Migrations also allow you to describe these transformation using ruby, in a database independent way (you can drop down to raw SQL for database specific features).
 
 You'll learn all about migrations including:
 
 * The generators you can use to create them
-* The methods ActiveRecord provides to manipulate your database
+* The methods Active Record provides to manipulate your database
 * The rake tasks that manipulate them
 * How they relate to schema.rb
 

railties/doc/guides/migrations/rakeing_around.txt

@@ -2,7 +2,7 @@
 
 Rails provides a set of rake tasks to work with migrations which boils down to running certain sets of migrations. The very first migration related rake task you use will probably be `db:migrate`. In its most basic form it just runs the up method for all the migrations that have not yet been run. If there are no such migrations it exits.
 
-If you specify a target version. ActiveRecord will run the required migrations (up or down) until it has reached the specified version. The
+If you specify a target version. Active Record will run the required migrations (up or down) until it has reached the specified version. The
 version is the numerical prefix on the migration's filename. For example to migrate to version 20080906120000 run
 
 `rake db:migrate VERSION=20080906120000`
@@ -37,7 +37,7 @@ If you need to run a specific migration up or down the `db:migrate:up` and `db:m
 
 `rake db:migrate:up VERSION=20080906120000`
 
-will run the up method from the 20080906120000 migration. These tasks check whether the migration has already run, so for example `db:migrate:up VERSION=20080906120000` will do nothing if ActiveRecord believes that 20080906120000 has already been run.
+will run the up method from the 20080906120000 migration. These tasks check whether the migration has already run, so for example `db:migrate:up VERSION=20080906120000` will do nothing if Active Record believes that 20080906120000 has already been run.
 
 
 === Being talkative ===
@@ -97,5 +97,5 @@ generates the following output
 == 20080906170109 CreateProducts: migrated (10.0097s) =========================
 ----------------------
 
-If you just want ActiveRecord to shut up then running `rake db:migrate VERBOSE=false` will suppress any output.
+If you just want Active Record to shut up then running `rake db:migrate VERBOSE=false` will suppress any output.
 

railties/doc/guides/migrations/scheming.txt

@@ -7,10 +7,10 @@ For example, this is how the test database is created: the current development d
 
 There are two ways to dump the schema. This is set in `config/environment.rb` by the `config.active_record.schema_format` setting, which may be either `:sql` or `:ruby`.
 
-If `:ruby` is selected then the schema is stored in `db/schema.rb`. If you look at this file you'll find that it looks an awful lot like one very big migration. In many ways this is exactly what it is. This file is created by inspecting the database and expressing its structure using `create_table`, `add_index` and so on. Because this is database independent it could be loaded into any database that ActiveRecord supports. This could be very useful if you were to distribute an application that is able to run against multiple databases.
+If `:ruby` is selected then the schema is stored in `db/schema.rb`. If you look at this file you'll find that it looks an awful lot like one very big migration. In many ways this is exactly what it is. This file is created by inspecting the database and expressing its structure using `create_table`, `add_index` and so on. Because this is database independent it could be loaded into any database that Active Record supports. This could be very useful if you were to distribute an application that is able to run against multiple databases.
 
 There is however a trade-off: `schema.rb` cannot express database specific items such as foreign key constraints. While in a migration you can execute custom sql statements, the schema dumper cannot reconstitute those statements from the database. If you are using features like this then you should set the schema format to `:sql`. 
 
-Instead of using ActiveRecord's schema dumper the database's structure will dumped using a tool specific to that database (via the `db:structure:dump` rake task) into `db/#\{RAILS_ENV\}_structure.sql`. For example for postgresql the `pg_dump` utility is used and for mysql this file will contain the output of SHOW CREATE TABLE for the various tables. Loading this schema is simply a question of executing the sql statements contained inside.
+Instead of using Active Record 's schema dumper the database's structure will dumped using a tool specific to that database (via the `db:structure:dump` rake task) into `db/#\{RAILS_ENV\}_structure.sql`. For example for postgresql the `pg_dump` utility is used and for mysql this file will contain the output of SHOW CREATE TABLE for the various tables. Loading this schema is simply a question of executing the sql statements contained inside.
 
 By definition this will be a perfect copy of the database's structure but this will usually prevent loading the schema into a database other than the one used to create it.

railties/doc/guides/migrations/using_models_in_migrations.txt

@@ -23,7 +23,7 @@ The migration has its own minimal copy of the `Product` model and no longer care
 
 === Dealing with changing models ===
 
-For performance reasons information about the columns a model has is cached. For example if you add a column to a table and then try and use the corresponding model to insert a new row it may try and use the old column information. You can force ActiveRecord to re-read the column information with the `reset_column_information` method, for example
+For performance reasons information about the columns a model has is cached. For example if you add a column to a table and then try and use the corresponding model to insert a new row it may try and use the old column information. You can force Active Record to re-read the column information with the `reset_column_information` method, for example
 
 [source, ruby]
 -------------------------

railties/doc/guides/migrations/writing_a_migration.txt

@@ -42,10 +42,10 @@ end
 ---------------------
 Will append `ENGINE=InnoDB` to the sql used to create the table.
 
-The types ActiveRecord supports are `:primary_key`, `:string`, `:text`, `:integer`, `:float`, `:decimal`, `:datetime`, `:timestamp`, `:time`, `:date`, `:binary`, `:boolean`.
+The types Active Record supports are `:primary_key`, `:string`, `:text`, `:integer`, `:float`, `:decimal`, `:datetime`, `:timestamp`, `:time`, `:date`, `:binary`, `:boolean`.
 
 These will be mapped onto an appropriate underlying database type, for example with MySQL `:string` is mapped to `VARCHAR(255)`. You can create columns of 
-types not supported by ActiveRecord when using the non sexy syntax, for example
+types not supported by Active Record when using the non sexy syntax, for example
 
 [source, ruby]
 ---------------------
@@ -83,7 +83,7 @@ You don't have to keep repeating the table name and it groups all the statements
 
 === Special helpers ===
 
-ActiveRecord provides some shortcuts for common functionality. It is for example very common to add both the `created_at` and `updated_at` columns and so there is a method that does exactly that:
+Active Record provides some shortcuts for common functionality. It is for example very common to add both the `created_at` and `updated_at` columns and so there is a method that does exactly that:
 
 [source, ruby]
 ---------------------
@@ -110,7 +110,7 @@ create_table :products do |t|
 end
 ---------------------
 
-will create a `category_id` column of the appropriate type. Note that you pass the model name, not the column name. ActiveRecord adds the `_id` for you. If you have polymorphic belongs_to associations then `references` will add both of the columns required:
+will create a `category_id` column of the appropriate type. Note that you pass the model name, not the column name. Active Record adds the `_id` for you. If you have polymorphic belongs_to associations then `references` will add both of the columns required:
 
 [source, ruby]
 ---------------------
@@ -122,7 +122,7 @@ will add an `attachment_id` column and a string `attachment_type` column with a
 
 NOTE: The `references` helper does not actually create foreign key constraints for you. You will need to use execute for that.
 
-If the helpers provided by ActiveRecord aren't enough you can use the `execute` function to execute arbitrary SQL.
+If the helpers provided by Active Record aren't enough you can use the `execute` function to execute arbitrary SQL.
 
 For more details and examples of individual methods check the API documentation.