diff options
Diffstat (limited to 'railties/doc/guides/source/migrations')
| -rw-r--r-- | railties/doc/guides/source/migrations/foreign_keys.txt | 2 | ||||
| -rw-r--r-- | railties/doc/guides/source/migrations/rakeing_around.txt | 2 | ||||
| -rw-r--r-- | railties/doc/guides/source/migrations/scheming.txt | 2 |
3 files changed, 3 insertions, 3 deletions
diff --git a/railties/doc/guides/source/migrations/foreign_keys.txt b/railties/doc/guides/source/migrations/foreign_keys.txt index 8f796843b2..792c41ccdc 100644 --- a/railties/doc/guides/source/migrations/foreign_keys.txt +++ b/railties/doc/guides/source/migrations/foreign_keys.txt @@ -1,6 +1,6 @@ [[foreign_key]] == Active Record and Referential Integrity == -The Active Record way is that intelligence belongs in your models, not in the database. As such features such as triggers or foreign key constraints, which push some of that intelligence back into the database are not heavily used. +The Active Record way is that intelligence belongs in your models, not in the database. As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database are not heavily used. Validations such as `validates_uniqueness_of` are one way in which models can enforce data integrity. The `:dependent` option on associations allows models to automatically destroy child objects when the parent is destroyed. Like anything which operates at the application level these cannot guarantee referential integrity and so some people augment them with foreign key constraints. diff --git a/railties/doc/guides/source/migrations/rakeing_around.txt b/railties/doc/guides/source/migrations/rakeing_around.txt index 1fcca0cf24..6d8c43d7a3 100644 --- a/railties/doc/guides/source/migrations/rakeing_around.txt +++ b/railties/doc/guides/source/migrations/rakeing_around.txt @@ -25,7 +25,7 @@ This will run the `down` method from the latest migration. If you need to undo s rake db:rollback STEP=3 ------------------ -will run the `down` method fron the last 3 migrations. +will run the `down` method from the last 3 migrations. The `db:migrate:redo` task is a shortcut for doing a rollback and then migrating back up again. As with the `db:rollback` task you can use the `STEP` parameter if you need to go more than one version back, for example diff --git a/railties/doc/guides/source/migrations/scheming.txt b/railties/doc/guides/source/migrations/scheming.txt index ba4fea8fe3..7acd3f9190 100644 --- a/railties/doc/guides/source/migrations/scheming.txt +++ b/railties/doc/guides/source/migrations/scheming.txt @@ -7,7 +7,7 @@ There is no need (and it is error prone) to deploy a new instance of an app by r For example, this is how the test database is created: the current development database is dumped (either to `schema.rb` or `development.sql`) and then loaded into the test database. -Schema files are also useful if 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 http://agilewebdevelopment.com/plugins/annotate_models[annotate_models] plugin, which automatically adds (and updates) comments at the top of each model summarising the schema, may also be of interest. +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 http://agilewebdevelopment.com/plugins/annotate_models[annotate_models] plugin, which automatically adds (and updates) comments at the top of each model summarising the schema, may also be of interest. === Types of schema dumps === 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`. |