<?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: Schema Generation in ORMs</title>
	<atom:link href="http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/</link>
	<description>Random stuff</description>
	<lastBuildDate>Wed, 28 Oct 2009 02:53:32 +0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Robert Ahrens</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/comment-page-1/#comment-461</link>
		<dc:creator>Robert Ahrens</dc:creator>
		<pubDate>Fri, 05 Oct 2007 14:51:22 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-461</guid>
		<description>I personally find the *lack* of schema generation to be an explicit feature of STORM.  

I&#039;m looking at building a set of Python webpages to expose an administrative interface to an existing db-driven app.  Without knowing *too* much about STORM, it seems like its design aims will really facilitate my placing an ORM layer atop an existing db, whereas with schema-generating ORMs I feel like this is a bolted on feature and involves some swimming upstream.

Nonetheless, I&#039;m pretty new to looking at Python ORMs and would be happy to be disabused of these notions by a more knowledgeable party.</description>
		<content:encoded><![CDATA[<p>I personally find the *lack* of schema generation to be an explicit feature of STORM.  </p>
<p>I&#8217;m looking at building a set of Python webpages to expose an administrative interface to an existing db-driven app.  Without knowing *too* much about STORM, it seems like its design aims will really facilitate my placing an ORM layer atop an existing db, whereas with schema-generating ORMs I feel like this is a bolted on feature and involves some swimming upstream.</p>
<p>Nonetheless, I&#8217;m pretty new to looking at Python ORMs and would be happy to be disabused of these notions by a more knowledgeable party.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Henstridge</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/comment-page-1/#comment-455</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Tue, 02 Oct 2007 04:28:31 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-455</guid>
		<description>Note that this article was about why we hadn&#039;t implemented schema generation (as SQLObject has with SQLObject.createTable() and SQLAlchemy has with Metadata.create_all()).  My point is that it seems counter-productive to provide a feature that is only suitable for toy projects, and the user will have to give up on as they progress.

The Ruby ActiveRecord system looks well designed, and much closer to what I&#039;d want to use.  That said, describing migrations in Python or Ruby code doesn&#039;t really appeal to me: SQL seems to do a fine job for the majority of migrations.</description>
		<content:encoded><![CDATA[<p>Note that this article was about why we hadn&#8217;t implemented schema generation (as SQLObject has with SQLObject.createTable() and SQLAlchemy has with Metadata.create_all()).  My point is that it seems counter-productive to provide a feature that is only suitable for toy projects, and the user will have to give up on as they progress.</p>
<p>The Ruby ActiveRecord system looks well designed, and much closer to what I&#8217;d want to use.  That said, describing migrations in Python or Ruby code doesn&#8217;t really appeal to me: SQL seems to do a fine job for the majority of migrations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Spiewak</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/comment-page-1/#comment-454</link>
		<dc:creator>Daniel Spiewak</dc:creator>
		<pubDate>Mon, 01 Oct 2007 17:06:52 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-454</guid>
		<description>Sounds like database migrations are what you&#039;re looking for.  ActiveRecord (ORM for Rails) provides these, as does ActiveObjects and a few other ORMs.  They can be a bit weird at times, especially on databases without flexible DDL ALTER statements.  However, they take care of a lot of the issues you enumerated.</description>
		<content:encoded><![CDATA[<p>Sounds like database migrations are what you&#8217;re looking for.  ActiveRecord (ORM for Rails) provides these, as does ActiveObjects and a few other ORMs.  They can be a bit weird at times, especially on databases without flexible DDL ALTER statements.  However, they take care of a lot of the issues you enumerated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Björn</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/comment-page-1/#comment-453</link>
		<dc:creator>Björn</dc:creator>
		<pubDate>Fri, 28 Sep 2007 22:33:20 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-453</guid>
		<description>Interesting article. It would also be interesting to know why you wrote yet another Python ORM when there are already are so many other excellent ones available. Storm vs. SQLObject or Storm vs. SQLAlchemy.. The linked site doesn&#039;t answer. Could be a topic for another article maybe?</description>
		<content:encoded><![CDATA[<p>Interesting article. It would also be interesting to know why you wrote yet another Python ORM when there are already are so many other excellent ones available. Storm vs. SQLObject or Storm vs. SQLAlchemy.. The linked site doesn&#8217;t answer. Could be a topic for another article maybe?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: riffraff</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/comment-page-1/#comment-452</link>
		<dc:creator>riffraff</dc:creator>
		<pubDate>Fri, 28 Sep 2007 16:07:08 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-452</guid>
		<description>well $ORM_FOR_FAMOUS_RUBY_FRAMEWORK has pure ruby migration scripts so that the schema can be evolved easily withouth touching SQL, and the definition of the initial schema is just the first migration. 
I don&#039;t think that there is anything wrong with defining the schema in SQL, but it seems close to what michele is suggesting in the above comment.</description>
		<content:encoded><![CDATA[<p>well $ORM_FOR_FAMOUS_RUBY_FRAMEWORK has pure ruby migration scripts so that the schema can be evolved easily withouth touching SQL, and the definition of the initial schema is just the first migration.<br />
I don&#8217;t think that there is anything wrong with defining the schema in SQL, but it seems close to what michele is suggesting in the above comment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: michele</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/comment-page-1/#comment-451</link>
		<dc:creator>michele</dc:creator>
		<pubDate>Fri, 28 Sep 2007 11:02:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-451</guid>
		<description>Hi James, 

I totally agree, anyway I do think that a python (or other language) based solution to schema definition and evolution could be very handy. But I&#039;m 100% sure that such a tool doesn&#039;t belong to an ORM and even more to it&#039;s &quot;mapping layer&quot;. It should be a completely standalone tool (not constrained to storm, sqlalchemy, ...) that allows you to define tables, columns, versioning and migrations using only python constructs, that way you could support different dbs within a single dsl.</description>
		<content:encoded><![CDATA[<p>Hi James, </p>
<p>I totally agree, anyway I do think that a python (or other language) based solution to schema definition and evolution could be very handy. But I&#8217;m 100% sure that such a tool doesn&#8217;t belong to an ORM and even more to it&#8217;s &#8220;mapping layer&#8221;. It should be a completely standalone tool (not constrained to storm, sqlalchemy, &#8230;) that allows you to define tables, columns, versioning and migrations using only python constructs, that way you could support different dbs within a single dsl.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
