<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The problem with Migrations</title>
	<atom:link href="http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/feed/" rel="self" type="application/rss+xml" />
	<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/</link>
	<description>A Weblog written, styled and hacked by Joel Moss</description>
	<pubDate>Fri, 05 Sep 2008 22:54:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Developing With Style &#187; Archive &#187; CakePHP Migrations v4.0 Beta</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-49</link>
		<dc:creator>Developing With Style &#187; Archive &#187; CakePHP Migrations v4.0 Beta</dc:creator>
		<pubDate>Tue, 20 May 2008 16:50:50 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-49</guid>
		<description>[...] The problem with Migrations   Categories [...]</description>
		<content:encoded><![CDATA[<p>[...] The problem with Migrations   Categories [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-48</link>
		<dc:creator>Keith</dc:creator>
		<pubDate>Mon, 19 May 2008 22:02:32 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-48</guid>
		<description>Ruby on Rails 2.1 is using the UTC timestamp methodology.  The concept that people would create their migration at exactly the same second is a pretty unlikely race scenario.  Given that a community of multi-developers as large as RoR has embraced this methodology I feel like the edge cases associated with issues would be small enough that it should be acceptable.  There is no more risk inherent in this method than in CakePHP's built in Schema tool.</description>
		<content:encoded><![CDATA[<p>Ruby on Rails 2.1 is using the UTC timestamp methodology.  The concept that people would create their migration at exactly the same second is a pretty unlikely race scenario.  Given that a community of multi-developers as large as RoR has embraced this methodology I feel like the edge cases associated with issues would be small enough that it should be acceptable.  There is no more risk inherent in this method than in CakePHP&#8217;s built in Schema tool.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: c_schmitz</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-45</link>
		<dc:creator>c_schmitz</dc:creator>
		<pubDate>Sun, 18 May 2008 14:06:02 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-45</guid>
		<description>Actually I see (saw) two problems with CakePHP Migrations:

- It uses PEAR 
- It is console only 

I solved both problems. I wrote a CakeMigration component based on your that still supports multiple DB types but without the need to install ADODB or PEAR, also it is a non-shell component so it can be run by any application (for example for the General update process).

I thought about  publishing it on the bakery but maybe we can join forces?</description>
		<content:encoded><![CDATA[<p>Actually I see (saw) two problems with CakePHP Migrations:</p>
<p>- It uses PEAR<br />
- It is console only </p>
<p>I solved both problems. I wrote a CakeMigration component based on your that still supports multiple DB types but without the need to install ADODB or PEAR, also it is a non-shell component so it can be run by any application (for example for the General update process).</p>
<p>I thought about  publishing it on the bakery but maybe we can join forces?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-33</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Sat, 10 May 2008 17:32:31 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-33</guid>
		<description>Time will tell...</description>
		<content:encoded><![CDATA[<p>Time will tell&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Hofstetter</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-30</link>
		<dc:creator>Daniel Hofstetter</dc:creator>
		<pubDate>Fri, 09 May 2008 07:20:18 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-30</guid>
		<description>@Joel: Yeah, sure, you probably can't avoid such conflicts with migrations. But with traditional version numbers it is obvious there is a conflict, whereas with timestamped version numbers you no longer see directly that there may be a conflict. But as I said in my first comment, it's possible that this is just a theoretical issue ;-)</description>
		<content:encoded><![CDATA[<p>@Joel: Yeah, sure, you probably can&#8217;t avoid such conflicts with migrations. But with traditional version numbers it is obvious there is a conflict, whereas with timestamped version numbers you no longer see directly that there may be a conflict. But as I said in my first comment, it&#8217;s possible that this is just a theoretical issue <img src='http://developingwithstyle.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-29</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Fri, 09 May 2008 01:24:59 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-29</guid>
		<description>That won't be a problem as timestamps will be UTC or GMT. So as long as you use the Migration shell script to generate the file, all will be fine.</description>
		<content:encoded><![CDATA[<p>That won&#8217;t be a problem as timestamps will be UTC or GMT. So as long as you use the Migration shell script to generate the file, all will be fine.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BradM</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-28</link>
		<dc:creator>BradM</dc:creator>
		<pubDate>Thu, 08 May 2008 14:56:00 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-28</guid>
		<description>I'm curious. Let's say there are 2 developers. One in England and one in the US working on the same project. Joe from England creates a migration file with a timestamp at 2:00pm is local time. Let's say the timestamp is 345678_create_user.yml Now Jim from US creates a migration at 12:00pm his local time and has a timestamp of 123456_create_user.yml

Even though Joe created his first at 2pm and Jim created his second at 12pm. Does this still account for the timezone difference?</description>
		<content:encoded><![CDATA[<p>I&#8217;m curious. Let&#8217;s say there are 2 developers. One in England and one in the US working on the same project. Joe from England creates a migration file with a timestamp at 2:00pm is local time. Let&#8217;s say the timestamp is 345678_create_user.yml Now Jim from US creates a migration at 12:00pm his local time and has a timestamp of 123456_create_user.yml</p>
<p>Even though Joe created his first at 2pm and Jim created his second at 12pm. Does this still account for the timezone difference?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-27</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Thu, 08 May 2008 13:35:27 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-27</guid>
		<description>well I get back from vacation this weekend, so hope to get it done next week. So if I had to guess, you should see something by the end of May.</description>
		<content:encoded><![CDATA[<p>well I get back from vacation this weekend, so hope to get it done next week. So if I had to guess, you should see something by the end of May.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RainChen</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-26</link>
		<dc:creator>RainChen</dc:creator>
		<pubDate>Thu, 08 May 2008 13:11:18 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-26</guid>
		<description>@Joel
I'm looking for some kind of Rails style migration on Cake for a long time.
You do the great job.
So,my next question is when will the next release come out.</description>
		<content:encoded><![CDATA[<p>@Joel<br />
I&#8217;m looking for some kind of Rails style migration on Cake for a long time.<br />
You do the great job.<br />
So,my next question is when will the next release come out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel</title>
		<link>http://developingwithstyle.com/2008/05/05/the-problem-with-migrations/#comment-25</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Thu, 08 May 2008 12:58:49 +0000</pubDate>
		<guid isPermaLink="false">http://developingwithstyle.com/?p=155#comment-25</guid>
		<description>@RainChen Sorry, but that is not supported in the CakePHP Migrations shell. Rails using Ruby code for their migration files, so you can write anything in there, but CakePHP Migrations uses YML, so you are somewhat limited.

However, as mentioned, the next release will allow you to write migration files using all PHP code and arrays. So you could do anything you want in there.</description>
		<content:encoded><![CDATA[<p>@RainChen Sorry, but that is not supported in the CakePHP Migrations shell. Rails using Ruby code for their migration files, so you can write anything in there, but CakePHP Migrations uses YML, so you are somewhat limited.</p>
<p>However, as mentioned, the next release will allow you to write migration files using all PHP code and arrays. So you could do anything you want in there.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
