<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Schema Generation in ORMs</title>
	<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/</link>
	<description>Random stuff</description>
	<pubDate>Sun, 06 Jul 2008 01:11:06 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Robert Ahrens</title>
		<link>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-461</link>
		<dc:creator>Robert Ahrens</dc:creator>
		<pubDate>Fri, 05 Oct 2007 14:51:22 +0000</pubDate>
		<guid>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'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'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-455</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Tue, 02 Oct 2007 04:28:31 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-455</guid>
		<description>Note that this article was about why we hadn'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'd want to use.  That said, describing migrations in Python or Ruby code doesn'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-454</link>
		<dc:creator>Daniel Spiewak</dc:creator>
		<pubDate>Mon, 01 Oct 2007 17:06:52 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2007/09/28/orm-schema-generation/#comment-454</guid>
		<description>Sounds like database migrations are what you'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-453</link>
		<dc:creator>Björn</dc:creator>
		<pubDate>Fri, 28 Sep 2007 22:33:20 +0000</pubDate>
		<guid>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'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-452</link>
		<dc:creator>riffraff</dc:creator>
		<pubDate>Fri, 28 Sep 2007 16:07:08 +0000</pubDate>
		<guid>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'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-451</link>
		<dc:creator>michele</dc:creator>
		<pubDate>Fri, 28 Sep 2007 11:02:12 +0000</pubDate>
		<guid>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'm 100% sure that such a tool doesn't belong to an ORM and even more to it's "mapping layer". 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>
