aboutsummaryrefslogtreecommitdiffstats
path: root/railties/guides/source
diff options
context:
space:
mode:
authorJared Giles <jared@aleph-one.net>2009-04-17 21:06:16 -0500
committerJared Giles <jared@aleph-one.net>2009-04-17 21:06:16 -0500
commit9f8b99ba576fc41b6ad97b0aa0cf25d11f675933 (patch)
tree1cab2f53eafa91da12d9669ee28e0e146d9696dc /railties/guides/source
parent938eb01c2418e2fd6fa1f466baec391f3c2085d7 (diff)
downloadrails-9f8b99ba576fc41b6ad97b0aa0cf25d11f675933.tar.gz
rails-9f8b99ba576fc41b6ad97b0aa0cf25d11f675933.tar.bz2
rails-9f8b99ba576fc41b6ad97b0aa0cf25d11f675933.zip
Updated migration section to mention that SQLite now supports transactional migrations
Diffstat (limited to 'railties/guides/source')
-rw-r--r--railties/guides/source/migrations.textile2
1 files changed, 1 insertions, 1 deletions
diff --git a/railties/guides/source/migrations.textile b/railties/guides/source/migrations.textile
index 5ed94c30b7..bcea5e0cb5 100644
--- a/railties/guides/source/migrations.textile
+++ b/railties/guides/source/migrations.textile
@@ -78,7 +78,7 @@ Active Record provides methods that perform common data definition tasks in a da
If you need to perform tasks specific to your database (for example create a "foreign key":#active-record-and-referential-integrity constraint) then the +execute+ function allows you to execute arbitrary SQL. A migration is just a regular Ruby class so you're not limited to these functions. For example after adding a column you could write code to set the value of that column for existing records (if necessary using your models).
-On databases that support transactions with statements that change the schema (such as PostgreSQL), migrations are wrapped in a transaction. If the database does not support this (for example MySQL and SQLite) then when a migration fails the parts of it that succeeded will not be rolled back. You will have to unpick the changes that were made by hand.
+On databases that support transactions with statements that change the schema (such as PostgreSQL or SQLite3), migrations are wrapped in a transaction. If the database does not support this (for example MySQL) then when a migration fails the parts of it that succeeded will not be rolled back. You will have to unpick the changes that were made by hand.
h4. What's in a Name