Saas 3.10- Databases And Migrations - Revision history

Rbyredd at 07:49, 3 October 2012

2012-10-03T07:49:04Z

← Older revision		Revision as of 07:49, 3 October 2012
Line 120:		Line 120:
	</pre>		</pre>

	== Creating a ~~Standlone~~ Migration==		== Creating a Standalone Migration ==
	If you are creating migrations for other purposes, then a migration generator is used:		If you are creating migrations for other purposes, then a migration generator is used:
	<pre>		<pre>
Line 151:		Line 151:
	</p>		</p>

	== Running ~~specific migrations~~ ==		== Running Specific Migrations ==
	<p>		<p>
	If you need to run a specific migration up or down, the db:migrate:up and db:migrate:downtasks will do that on including the version also.		If you need to run a specific migration up or down, the db:migrate:up and db:migrate:downtasks will do that on including the version also.
Line 162:		Line 162:
	</p>		</p>

	== Rolling Back a ~~migration~~ ==		== Rolling Back a Migration ==
	<p>		<p>
	The following command is used to rollback the last migration:		The following command is used to rollback the last migration:

2012-10-03T07:47:24Z

Disadvantages of Migrations

← Older revision		Revision as of 07:47, 3 October 2012
Line 213:		Line 213:
	</ol>		</ol>

	== Disadvantages of ~~Migrations~~ ==		== Disadvantages of Migration ==
	<ol>		<ol>
	<li>One drawback of Rails migrations is that all migrations occur at the database level, not the table level.</li>		<li>One drawback of Rails migrations is that all migrations occur at the database level, not the table level.</li>

2012-10-03T07:45:56Z

Creating a standalone

← Older revision		Revision as of 07:45, 3 October 2012
Line 120:		Line 120:
	</pre>		</pre>

	== Creating a ~~standalone~~ ==		== Creating a Standlone Migration==
	If you are creating migrations for other purposes, then a migration generator is used:		If you are creating migrations for other purposes, then a migration generator is used:
	<pre>		<pre>

2012-10-03T07:44:50Z

← Older revision		Revision as of 07:44, 3 October 2012
Line 227:		Line 227:
	== References ==		== References ==
	<references/>		<references/>

			== Additional Reading ==
			<ol>
			<li>http://guides.rubyonrails.org/migrations.html#anatomy-of-a-migration</li>
			<li>http://www.ibm.com/developerworks/java/library/j-cb08156/index.html</li>
			<li>http://jacqueschirag.wordpress.com/2007/08/12/rants-about-rails-database-migrations</li>
			<li>http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html</li>
			<li>Agile Web Development With Rails, Fourth Edition, Sam Rooby, Dave Thomas, David Heinemeier Hansson.</li>
			</ol>

2012-10-03T07:43:05Z

← Older revision		Revision as of 07:43, 3 October 2012
Line 213:		Line 213:
	</ol>		</ol>

	== Disadvantages of ~~migrations~~ ==		== Disadvantages of Migrations ==
	<ol>		<ol>
	<li>One drawback of Rails migrations is that all migrations occur at the database level, not the table level.</li>		<li>One drawback of Rails migrations is that all migrations occur at the database level, not the table level.</li>
Line 219:		Line 219:
	<li>Most databases do not prop up the rolling back of data definition language(DDL) statements.</li>		<li>Most databases do not prop up the rolling back of data definition language(DDL) statements.</li>
	</ol>		</ol>

			== Conclusion ==
			<p>
			In a nutshell, Database Migration is a very efficient way to handle the discrepancies that occur between databases. i.e. changes made in one database not reflecting in other. It is a convenient way to alter the database in structured and organized manner. Rails migrations are mostly similar to version control of databases. Rails migrations are database independent but SQL scripts are not.
			</p>

	== References ==		== References ==
	<references/>		<references/>
	~~migration~~

2012-10-03T07:41:53Z

← Older revision		Revision as of 07:41, 3 October 2012
Line 211:		Line 211:
	<li>Migrations can be managed with version control.</li>		<li>Migrations can be managed with version control.</li>
	<li>Automation – Automate things to be done which makes it reliably repeatable. For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.</li>		<li>Automation – Automate things to be done which makes it reliably repeatable. For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.</li>
			</ol>

			== Disadvantages of migrations ==
			<ol>
			<li>One drawback of Rails migrations is that all migrations occur at the database level, not the table level.</li>
			<li>The whole discussion about Migration suggest that they are dangerous to use on production database. One should backup the database first and then use migrations on the production database.</li>
			<li>Most databases do not prop up the rolling back of data definition language(DDL) statements.</li>
	</ol>		</ol>

2012-10-03T07:40:24Z

← Older revision		Revision as of 07:40, 3 October 2012
Line 211:		Line 211:
	<li>Migrations can be managed with version control.</li>		<li>Migrations can be managed with version control.</li>
	<li>Automation – Automate things to be done which makes it reliably repeatable. For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.</li>		<li>Automation – Automate things to be done which makes it reliably repeatable. For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.</li>
	<ol>		</ol>

	== References ==		== References ==
	<references/>		<references/>
	migration		migration

2012-10-03T07:39:52Z

← Older revision		Revision as of 07:39, 3 October 2012
Line 204:		Line 204:
	wasn’t updated. So you cannot roll back it. One solution to the above problem is, to manually change the schema information and drop the table first. But, it is recommended in these cases to simply drop the whole database, create the whole thing again and apply migrations to bring it back to the original state.		wasn’t updated. So you cannot roll back it. One solution to the above problem is, to manually change the schema information and drop the table first. But, it is recommended in these cases to simply drop the whole database, create the whole thing again and apply migrations to bring it back to the original state.
	</p>		</p>

			== Advantages of Migration ==
			<ol>
			<li>You can identify each migration and know when it has taken place.</li>
			<li>Some migrations can also be rolled back. We can specify what the roll back procedure is.</li>
			<li>Migrations can be managed with version control.</li>
			<li>Automation – Automate things to be done which makes it reliably repeatable. For example, In Ruby on Rails, we use Bundler instead of installing all gems manually. In short, specify what needs to be done and automate it.</li>
			<ol>

	== References ==		== References ==
	<references/>		<references/>
	migration		migration

2012-10-03T07:36:36Z

@@ Line 179: / Line 179: @@
 </pre>
 “rake db:reset” is the command for resetting the database. This will drop the databse, recreate it and loads the current schema into it.
 </p>

2012-10-03T07:33:05Z

@@ Line 160: / Line 160: @@
 </pre><p>
 The above command will run the up method from the 20080906120000 migration. These tasks still 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.
 </p>