<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Strategies for upgrading webapps?</title>
	<atom:link href="http://www.jasonawesome.com/2010/01/13/strategies-for-upgrading-webapps/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jasonawesome.com/2010/01/13/strategies-for-upgrading-webapps/</link>
	<description>Life and times of a PHP Developer in Raleigh, NC</description>
	<lastBuildDate>Mon, 09 Aug 2010 14:43:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Keith Casey</title>
		<link>http://www.jasonawesome.com/2010/01/13/strategies-for-upgrading-webapps/comment-page-1/#comment-665</link>
		<dc:creator>Keith Casey</dc:creator>
		<pubDate>Thu, 14 Jan 2010 19:31:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonawesome.com/?p=300#comment-665</guid>
		<description>I&#039;ve been struggling with much the same situation with web2project upgrades. Managing the database - especially in an engine-agnostic way - is a pain. At DCPHP last night, someone suggested that the app itself might not be the place for it and suggested that Rails might be a good fit.

It&#039;s not a good fit for us - the app is open source and we have no knowledge/control of the configuration - but it might be an option for you. There&#039;s no reason that *everything* has to be 100% PHP all the time.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been struggling with much the same situation with web2project upgrades. Managing the database &#8211; especially in an engine-agnostic way &#8211; is a pain. At DCPHP last night, someone suggested that the app itself might not be the place for it and suggested that Rails might be a good fit.</p>
<p>It&#8217;s not a good fit for us &#8211; the app is open source and we have no knowledge/control of the configuration &#8211; but it might be an option for you. There&#8217;s no reason that *everything* has to be 100% PHP all the time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bradley Holt</title>
		<link>http://www.jasonawesome.com/2010/01/13/strategies-for-upgrading-webapps/comment-page-1/#comment-662</link>
		<dc:creator>Bradley Holt</dc:creator>
		<pubDate>Wed, 13 Jan 2010 20:56:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonawesome.com/?p=300#comment-662</guid>
		<description>I don&#039;t have a lot of experience with dbdeploy, but my understanding is that you just write SQL scripts so you could have both DDL (e.g. CREATE TABLE...) and DML (e.g. INSERT INTO...) in these scripts. Ideally you&#039;d write both an UP and DOWN version of each script so you could do rollbacks too.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t have a lot of experience with dbdeploy, but my understanding is that you just write SQL scripts so you could have both DDL (e.g. CREATE TABLE&#8230;) and DML (e.g. INSERT INTO&#8230;) in these scripts. Ideally you&#8217;d write both an UP and DOWN version of each script so you could do rollbacks too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Awesome</title>
		<link>http://www.jasonawesome.com/2010/01/13/strategies-for-upgrading-webapps/comment-page-1/#comment-661</link>
		<dc:creator>Jason Awesome</dc:creator>
		<pubDate>Wed, 13 Jan 2010 20:51:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonawesome.com/?p=300#comment-661</guid>
		<description>We looked at dbdeploy, and it will take us half way there I think.  While versioning the schemas is a step in the right direction, we also have an issue where some type of manipulation of the data in the database is needed.  For instance, if you have a table with an attribute of phone_number, but in the next version you need to pull that attribute out so &lt;em&gt;n&lt;/em&gt; amounts of phone numbers can be assigned to a user.  You need to copy all the data from the existing field into the new table, then drop the original column, all while maintaining keys.  Will dbdeploy help with that?

I guess I am trying to get my head around doing this without having to use PHP to do some kind of magic.</description>
		<content:encoded><![CDATA[<p>We looked at dbdeploy, and it will take us half way there I think.  While versioning the schemas is a step in the right direction, we also have an issue where some type of manipulation of the data in the database is needed.  For instance, if you have a table with an attribute of phone_number, but in the next version you need to pull that attribute out so <em>n</em> amounts of phone numbers can be assigned to a user.  You need to copy all the data from the existing field into the new table, then drop the original column, all while maintaining keys.  Will dbdeploy help with that?</p>
<p>I guess I am trying to get my head around doing this without having to use PHP to do some kind of magic.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bradley Holt</title>
		<link>http://www.jasonawesome.com/2010/01/13/strategies-for-upgrading-webapps/comment-page-1/#comment-660</link>
		<dc:creator>Bradley Holt</dc:creator>
		<pubDate>Wed, 13 Jan 2010 20:44:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonawesome.com/?p=300#comment-660</guid>
		<description>I&#039;d take a look at dbdeploy or LiquiBase if you haven&#039;t already. I&#039;ve experimented a bit with dbdeploy but haven&#039;t tried LiquiBase yet. There&#039;s a dbdeploy task in Phing which could help quite a bit.</description>
		<content:encoded><![CDATA[<p>I&#8217;d take a look at dbdeploy or LiquiBase if you haven&#8217;t already. I&#8217;ve experimented a bit with dbdeploy but haven&#8217;t tried LiquiBase yet. There&#8217;s a dbdeploy task in Phing which could help quite a bit.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
