<?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: Rails schema migrations</title>
	<atom:link href="http://blog.amber.org/2006/02/20/rails-schema-migrations/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.amber.org/2006/02/20/rails-schema-migrations/</link>
	<description>Thoughts of a minor lunatic</description>
	<pubDate>Fri, 29 Aug 2008 22:27:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: petrilli</title>
		<link>http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5431</link>
		<dc:creator>petrilli</dc:creator>
		<pubDate>Tue, 21 Feb 2006 02:41:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5431</guid>
		<description>That's unfortunate, since being able to maintain DDL inside a transaction -- thereby making sure you commit all your changes or none -- is a huge benefit to making sure that the database stays in a stable state. The ability to migrate up and down is seriously degraded in its trustworthiness by the fact that you could get the database hung in strange situations.

Ah well, I'm sure transactions are just a passing fad after all.</description>
		<content:encoded><![CDATA[<p>That&#8217;s unfortunate, since being able to maintain DDL inside a transaction&#8212;thereby making sure you commit all your changes or none&#8212;is a huge benefit to making sure that the database stays in a stable state. The ability to migrate up and down is seriously degraded in its trustworthiness by the fact that you could get the database hung in strange situations.</p>
<p>Ah well, I&#8217;m sure transactions are just a passing fad after all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Koziarski</title>
		<link>http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5430</link>
		<dc:creator>Michael Koziarski</dc:creator>
		<pubDate>Tue, 21 Feb 2006 02:37:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5430</guid>
		<description>Most of the other databases seem to either commit the moment you issue DDL or just bark at you for trying but carry on anyway.  (psql </description>
		<content:encoded><![CDATA[<p>Most of the other databases seem to either commit the moment you issue DDL or just bark at you for trying but carry on anyway.  (psql </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: petrilli</title>
		<link>http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5419</link>
		<dc:creator>petrilli</dc:creator>
		<pubDate>Mon, 20 Feb 2006 18:53:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5419</guid>
		<description>Almost everything I do is on PostgreSQL. I do believe, however, that Oracle also allows DDL to be performed inside a transaction, but I could be wrong.

@NUMERIC@ seems to get treated as a Float, which is _mega evil_ in the grand scheme of things. Right now, I'm actually not using @NUMERIC@ in this app, since I'm using the @INET@ type.  This just gets treated as a @String@ basically.  Seems to work so far, but I haven't tried using the strange searching pieces.

I'm using the PostgreSQL C adapter, not the Ruby-native one.  If it's only supported by PostgreSQL, then it doesn't make sense necessarily to integrate it into the trunk.</description>
		<content:encoded><![CDATA[<p>Almost everything I do is on PostgreSQL. I do believe, however, that Oracle also allows DDL to be performed inside a transaction, but I could be wrong.</p>
<p><code>NUMERIC</code> seems to get treated as a Float, which is <em>mega evil</em> in the grand scheme of things. Right now, I&#8217;m actually not using <code>NUMERIC</code> in this app, since I&#8217;m using the <code>INET</code> type.  This just gets treated as a <code>String</code> basically.  Seems to work so far, but I haven&#8217;t tried using the strange searching pieces.</p>
<p>I&#8217;m using the PostgreSQL C adapter, not the Ruby-native one.  If it&#8217;s only supported by PostgreSQL, then it doesn&#8217;t make sense necessarily to integrate it into the trunk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Koziarski</title>
		<link>http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5416</link>
		<dc:creator>Michael Koziarski</dc:creator>
		<pubDate>Mon, 20 Feb 2006 18:10:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amber.org/2006/02/20/rails-schema-migrations/#comment-5416</guid>
		<description>Hey there,

Which Database adapter are you using?   DDL and transactions aren't integrated in mysql, oracle or DB2.  Though they do seem to work in postgres.  I'll add support for transactional migrations to trunk.

Numeric is another good point,  I haven't done financial apps with cents since switching to rails full time,  but it's definitely missing.

Does the rest of AR behave for you with numeric columns?</description>
		<content:encoded><![CDATA[<p>Hey there,</p>
<p>Which Database adapter are you using?   DDL and transactions aren&#8217;t integrated in mysql, oracle or DB2.  Though they do seem to work in postgres.  I&#8217;ll add support for transactional migrations to trunk.</p>
<p>Numeric is another good point,  I haven&#8217;t done financial apps with cents since switching to rails full time,  but it&#8217;s definitely missing.</p>
<p>Does the rest of AR behave for you with numeric columns?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.222 seconds -->
