<?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: ErlyDB 0.7</title>
	<atom:link href="http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/feed/" rel="self" type="application/rss+xml" />
	<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/</link>
	<description>Adventures in Open Source Erlang</description>
	<lastBuildDate>Sun, 06 Dec 2009 10:29:08 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bestiality porn zoo sex private photo and movies.</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-299207</link>
		<dc:creator>Bestiality porn zoo sex private photo and movies.</dc:creator>
		<pubDate>Mon, 10 Nov 2008 00:38:28 +0000</pubDate>
		<guid isPermaLink="false">#comment-299207</guid>
		<description>&lt;strong&gt;Dog porn movies zoo porn movies animal porn movies....&lt;/strong&gt;

Beast sex zoo sex animal porn. Zoo sex beastiality horse porn dog fucking....</description>
		<content:encoded><![CDATA[<p><strong>Dog porn movies zoo porn movies animal porn movies&#8230;.</strong></p>
<p>Beast sex zoo sex animal porn. Zoo sex beastiality horse porn dog fucking&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jwewymolusa</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-97579</link>
		<dc:creator>jwewymolusa</dc:creator>
		<pubDate>Sun, 10 Feb 2008 14:00:28 +0000</pubDate>
		<guid isPermaLink="false">#comment-97579</guid>
		<description>But then stopped, &lt;a href=&quot;http://akerman.mypunbb.com&quot; rel=&quot;nofollow&quot;&gt;malin akerman nude&lt;/a&gt; that much longer, be doing your facts.</description>
		<content:encoded><![CDATA[<p>But then stopped, <a href="http://akerman.mypunbb.com" rel="nofollow">malin akerman nude</a> that much longer, be doing your facts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Norbert Klamann</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-19558</link>
		<dc:creator>Norbert Klamann</dc:creator>
		<pubDate>Fri, 30 Mar 2007 12:59:06 +0000</pubDate>
		<guid isPermaLink="false">#comment-19558</guid>
		<description>@arjw wrt. database independence.

IMHO not a great idea at all. Use the database to its fullest extent ! You never get as much security and performance for the buck as in the database itself.

[Disclaimer] I do Oracle DB-Development for a living.</description>
		<content:encoded><![CDATA[<p>@arjw wrt. database independence.</p>
<p>IMHO not a great idea at all. Use the database to its fullest extent ! You never get as much security and performance for the buck as in the database itself.</p>
<p>[Disclaimer] I do Oracle DB-Development for a living.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yariv</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-389</link>
		<dc:creator>Yariv</dc:creator>
		<pubDate>Mon, 02 Oct 2006 12:09:13 +0000</pubDate>
		<guid isPermaLink="false">#comment-389</guid>
		<description>Thanks for everybody&#039;s input!</description>
		<content:encoded><![CDATA[<p>Thanks for everybody&#8217;s input!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yariv</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-388</link>
		<dc:creator>Yariv</dc:creator>
		<pubDate>Mon, 02 Oct 2006 12:08:34 +0000</pubDate>
		<guid isPermaLink="false">#comment-388</guid>
		<description>Regarding schema generation -- it&#039;s simple enough to do. Maybe I&#039;ll try to hack something for the next ErlyDB release. About namespace collisions -- I think the likelyhood of a collision is low enough for this to not be such a big concern. However, if it does happen, it can be annoying. I don&#039;t see it as an urgent issue, but maybe I&#039;ll find an easy way to add an ErlyDB prefix to generated functions for a future release. For hooks -- you can call the is_new/1 function of the domain modules to check for INSERT or UPDATE statements in the before_save hook. In the after_X hooks, they always apply to a single record. If the DELETE or UPDATE statements don&#039;t affect a single record, an error is thrown telling you how many records were affected in the database. Isn&#039;t that sufficient?
</description>
		<content:encoded><![CDATA[<p>Regarding schema generation &#8212; it&#8217;s simple enough to do. Maybe I&#8217;ll try to hack something for the next ErlyDB release. About namespace collisions &#8212; I think the likelyhood of a collision is low enough for this to not be such a big concern. However, if it does happen, it can be annoying. I don&#8217;t see it as an urgent issue, but maybe I&#8217;ll find an easy way to add an ErlyDB prefix to generated functions for a future release. For hooks &#8212; you can call the is_new/1 function of the domain modules to check for INSERT or UPDATE statements in the before_save hook. In the after_X hooks, they always apply to a single record. If the DELETE or UPDATE statements don&#8217;t affect a single record, an error is thrown telling you how many records were affected in the database. Isn&#8217;t that sufficient?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitrii Dimandt aka Mamut</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-386</link>
		<dc:creator>Dmitrii Dimandt aka Mamut</dc:creator>
		<pubDate>Mon, 02 Oct 2006 02:48:22 +0000</pubDate>
		<guid isPermaLink="false">#comment-386</guid>
		<description>One word: Whoah!  Automatic table generation or table migrations (a la Rails?) could be a plus, though</description>
		<content:encoded><![CDATA[<p>One word: Whoah!  Automatic table generation or table migrations (a la Rails?) could be a plus, though</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ajrw</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-385</link>
		<dc:creator>ajrw</dc:creator>
		<pubDate>Sun, 01 Oct 2006 23:53:50 +0000</pubDate>
		<guid isPermaLink="false">#comment-385</guid>
		<description>Hm, clicking on the submit button seems to add a comment without giving any feedback (such as moving to a new page). Inappropriate use of Ajax? :)</description>
		<content:encoded><![CDATA[<p>Hm, clicking on the submit button seems to add a comment without giving any feedback (such as moving to a new page). Inappropriate use of Ajax? :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ajrw</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-384</link>
		<dc:creator>ajrw</dc:creator>
		<pubDate>Sun, 01 Oct 2006 23:51:27 +0000</pubDate>
		<guid isPermaLink="false">#comment-384</guid>
		<description>Yariv: The nice thing about programmatic table creation is that you can write to one (common subset) schema and maintain portability across different database servers. There&#039;s also the possibility for automatic database upgrades as new fields are added or existing ones are modified.

In particular I&#039;m thinking of SugarCRM&#039;s &quot;vardefs.php&quot; files, which define various metadata for each of the database (and virtual) fields, such as the column type and size. The field descriptor also covers things like formatting conventions, for automatic conversion from the user&#039;s display/edit format to the database storage format - useful when handling lots of dates and currency amounts.

Perhaps this sort of thing would be better implemented as a layer over ErlyDB.</description>
		<content:encoded><![CDATA[<p>Yariv: The nice thing about programmatic table creation is that you can write to one (common subset) schema and maintain portability across different database servers. There&#8217;s also the possibility for automatic database upgrades as new fields are added or existing ones are modified.</p>
<p>In particular I&#8217;m thinking of SugarCRM&#8217;s &#8220;vardefs.php&#8221; files, which define various metadata for each of the database (and virtual) fields, such as the column type and size. The field descriptor also covers things like formatting conventions, for automatic conversion from the user&#8217;s display/edit format to the database storage format &#8211; useful when handling lots of dates and currency amounts.</p>
<p>Perhaps this sort of thing would be better implemented as a layer over ErlyDB.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ke han</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-383</link>
		<dc:creator>ke han</dc:creator>
		<pubDate>Sun, 01 Oct 2006 23:21:47 +0000</pubDate>
		<guid isPermaLink="false">#comment-383</guid>
		<description>in addition to the resolution on save hooks, having access to information in the after hooks for fetch, save and delete would be useful.  This additional info would inlcude the number of rows effected by the operation. </description>
		<content:encoded><![CDATA[<p>in addition to the resolution on save hooks, having access to information in the after hooks for fetch, save and delete would be useful.  This additional info would inlcude the number of rows effected by the operation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ke han</title>
		<link>http://yarivsblog.com/articles/2006/09/30/erlydb-0-7/comment-page-1/#comment-382</link>
		<dc:creator>ke han</dc:creator>
		<pubDate>Sun, 01 Oct 2006 23:17:56 +0000</pubDate>
		<guid isPermaLink="false">#comment-382</guid>
		<description>your before_save and after_save functions do not provide enough resolution.  In many cases, you need to know if the save was an update or a create.  I recommend either offering additional before_update, before_create, etc... or have an optional parameter to the save hooks to pass the context of the operation.  You could have a before_save/2 which can be used like:
before_save(Model, Context) where Context == update.</description>
		<content:encoded><![CDATA[<p>your before_save and after_save functions do not provide enough resolution.  In many cases, you need to know if the save was an update or a create.  I recommend either offering additional before_update, before_create, etc&#8230; or have an optional parameter to the save hooks to pass the context of the operation.  You could have a before_save/2 which can be used like:<br />
before_save(Model, Context) where Context == update.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
