<?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: Dumbledore Gets It, Why Doesn&#8217;t Data?</title>
	<atom:link href="http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/feed/" rel="self" type="application/rss+xml" />
	<link>http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/</link>
	<description>no significant tagline</description>
	<pubDate>Thu, 28 Aug 2008 16:08:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: Bill Higgins</title>
		<link>http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/#comment-1169</link>
		<dc:creator>Bill Higgins</dc:creator>
		<pubDate>Sun, 28 Oct 2007 01:41:00 +0000</pubDate>
		<guid isPermaLink="false">http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/#comment-1169</guid>
		<description>Jazz currently uses an RDB as its persistence mechanism, though we *claim* this is an implementation detail. On the server-side, Jazz clients interact with a logical repository via a set of Java APIs. The superclass of all 'things' in a Jazz repository is called "Item" (which is like Object but with persistence and more reflective capabilities). Under Item there are several subclasses, one of which is called "Auditable". Any Jazz component may define 0-n new Item types (e.g. "Requirement", "Iteration Plan", etc). If a Jazz component defines a new Item type and subclasses Auditable, they get versioning for free. To be precise, each successful save of an item descending from Auditable results in a new immutable persistent version of the item in the Repository. Likewise clients can use other APIs to request either the current version or one of the earlier versions of an Auditable item.

From an RDB perspective, saving an Auditable results in the creation of a new row in some table in the database, rather than updating a pre-existing row (I think JoeG said this was a pretty common pattern, but I'm not a persistence wonk so I'm not sure).

In theory, since clients interact with high-level repository APIs rather than RDB-centric APIs (like JDBC), if a persistence mechanism came along that provided native versioning support, and still provided adequate concurrency and query capabilities, we could switch to that native mechanism without clients noticing. But I don't expect this to happen anytime soon. Also, it's a stretch to claim that "the RDB is an implementation detail" when it's the only implementation; I'm sure the law of leaky abstractions would rear its ugly head if/when we tried to plug in the second implementation.

I don't follow what you're saying about "Content". To me "Content" means "A dataset whose structure is opaque to the Repository". I.e. from the server's perspective it's just a sequence of bytes (though it might have some structure which the server simply doesn't understand). We have such a notion in Jazz, and it's straightforward to use the same Auditable versioning mechanism. Simply wrap a Content object in an Auditable. E.g. define a new Auditable type called "File" which has a single attribute "content" referencing a content object (obviously you'd want more attributes for a file). I don't know if what I've just described has anything to do with what you were talking about but I'd be interested to hear if what I said raised or settled any issues.</description>
		<content:encoded><![CDATA[<p>Jazz currently uses an RDB as its persistence mechanism, though we *claim* this is an implementation detail. On the server-side, Jazz clients interact with a logical repository via a set of Java APIs. The superclass of all &#8216;things&#8217; in a Jazz repository is called &#8220;Item&#8221; (which is like Object but with persistence and more reflective capabilities). Under Item there are several subclasses, one of which is called &#8220;Auditable&#8221;. Any Jazz component may define 0-n new Item types (e.g. &#8220;Requirement&#8221;, &#8220;Iteration Plan&#8221;, etc). If a Jazz component defines a new Item type and subclasses Auditable, they get versioning for free. To be precise, each successful save of an item descending from Auditable results in a new immutable persistent version of the item in the Repository. Likewise clients can use other APIs to request either the current version or one of the earlier versions of an Auditable item.</p>
<p>From an RDB perspective, saving an Auditable results in the creation of a new row in some table in the database, rather than updating a pre-existing row (I think JoeG said this was a pretty common pattern, but I&#8217;m not a persistence wonk so I&#8217;m not sure).</p>
<p>In theory, since clients interact with high-level repository APIs rather than RDB-centric APIs (like JDBC), if a persistence mechanism came along that provided native versioning support, and still provided adequate concurrency and query capabilities, we could switch to that native mechanism without clients noticing. But I don&#8217;t expect this to happen anytime soon. Also, it&#8217;s a stretch to claim that &#8220;the RDB is an implementation detail&#8221; when it&#8217;s the only implementation; I&#8217;m sure the law of leaky abstractions would rear its ugly head if/when we tried to plug in the second implementation.</p>
<p>I don&#8217;t follow what you&#8217;re saying about &#8220;Content&#8221;. To me &#8220;Content&#8221; means &#8220;A dataset whose structure is opaque to the Repository&#8221;. I.e. from the server&#8217;s perspective it&#8217;s just a sequence of bytes (though it might have some structure which the server simply doesn&#8217;t understand). We have such a notion in Jazz, and it&#8217;s straightforward to use the same Auditable versioning mechanism. Simply wrap a Content object in an Auditable. E.g. define a new Auditable type called &#8220;File&#8221; which has a single attribute &#8220;content&#8221; referencing a content object (obviously you&#8217;d want more attributes for a file). I don&#8217;t know if what I&#8217;ve just described has anything to do with what you were talking about but I&#8217;d be interested to hear if what I said raised or settled any issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: brandon</title>
		<link>http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/#comment-1024</link>
		<dc:creator>brandon</dc:creator>
		<pubDate>Wed, 26 Sep 2007 02:35:49 +0000</pubDate>
		<guid isPermaLink="false">http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/#comment-1024</guid>
		<description>Pat,

True. IBM Rational Jazz does version data in its Repository implementation. But I believe, like most systems that version its data, it is solved at the application layer rather than the persistence layer. Generally not true when the data is called 'content'.

To most, data is synonymous with SQL. As such, is there a relational database that versions data transparent to the application, yet provide hooks for the application to retrieve versions?

So, perhaps it may be relevant to ask whether all data is so called 'content'?</description>
		<content:encoded><![CDATA[<p>Pat,</p>
<p>True. IBM Rational Jazz does version data in its Repository implementation. But I believe, like most systems that version its data, it is solved at the application layer rather than the persistence layer. Generally not true when the data is called &#8216;content&#8217;.</p>
<p>To most, data is synonymous with SQL. As such, is there a relational database that versions data transparent to the application, yet provide hooks for the application to retrieve versions?</p>
<p>So, perhaps it may be relevant to ask whether all data is so called &#8216;content&#8217;?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Mueller</title>
		<link>http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/#comment-1022</link>
		<dc:creator>Patrick Mueller</dc:creator>
		<pubDate>Tue, 25 Sep 2007 16:07:38 +0000</pubDate>
		<guid isPermaLink="false">http://16cards.com/2007/09/25/dumbledore-gets-it-why-doesnt-data/#comment-1022</guid>
		<description>Jazz, http://jazz.net , has been doing a pretty good job in playing with the space.  There are plenty of issues and challenges, but lots of benefit.</description>
		<content:encoded><![CDATA[<p>Jazz, <a href="http://jazz.net" rel="nofollow">http://jazz.net</a> , has been doing a pretty good job in playing with the space.  There are plenty of issues and challenges, but lots of benefit.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
