<?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: &#8220;updated&#8221; or &#8220;modified&#8221;</title>
	<atom:link href="http://cakebaker.42dh.com/2008/10/28/updated-or-modified/feed/" rel="self" type="application/rss+xml" />
	<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/</link>
	<description>baking cakes with CakePHP</description>
	<lastBuildDate>Wed, 12 Jun 2013 01:23:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: frankeinstein</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-279615</link>
		<dc:creator>frankeinstein</dc:creator>
		<pubDate>Wed, 06 Jun 2012 14:50:21 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-279615</guid>
		<description><![CDATA[I&#039;m pretty sure the &quot;U&quot; in &quot;CRUD&quot; stands for &quot;Update&quot;, and since CRUD appears throughout Cake documentation, it seems only logical that the field names would be “created” and “updated”.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m pretty sure the &#8220;U&#8221; in &#8220;CRUD&#8221; stands for &#8220;Update&#8221;, and since CRUD appears throughout Cake documentation, it seems only logical that the field names would be “created” and “updated”.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cakebaker</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-278278</link>
		<dc:creator>cakebaker</dc:creator>
		<pubDate>Wed, 23 May 2012 13:21:25 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-278278</guid>
		<description><![CDATA[@mark: Good to see such old things are discussed by the core devs :)]]></description>
		<content:encoded><![CDATA[<p>@mark: Good to see such old things are discussed by the core devs :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mark</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-277232</link>
		<dc:creator>mark</dc:creator>
		<pubDate>Wed, 09 May 2012 14:51:14 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-277232</guid>
		<description><![CDATA[I think it is worth discussing:
http://cakephp.lighthouseapp.com/projects/42648-cakephp/tickets/2870-magic-datetime-fields-should-be-reduced-to-created-and-modified-aliasing]]></description>
		<content:encoded><![CDATA[<p>I think it is worth discussing:<br />
<a href="http://cakephp.lighthouseapp.com/projects/42648-cakephp/tickets/2870-magic-datetime-fields-should-be-reduced-to-created-and-modified-aliasing" rel="nofollow">http://cakephp.lighthouseapp.com/projects/42648-cakephp/tickets/2870-magic-datetime-fields-should-be-reduced-to-created-and-modified-aliasing</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cakebaker</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111689</link>
		<dc:creator>cakebaker</dc:creator>
		<pubDate>Thu, 30 Oct 2008 16:05:14 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111689</guid>
		<description><![CDATA[@all: Thanks for your comments!

@grigri: Yeah, moving the functionality to a behavior could make it more flexible. On the other hand I&#039;m not sure whether such a flexibility is really necessary... Probably the approach mentioned by Jonah would be a good compromise. 

@Jonah: Yes, that&#039;s a good idea!

@ajmacaro: Yes, that&#039;s probably the reason. Only, it doesn&#039;t make it simpler, it makes it more &quot;complex&quot; because people now have to learn about two conventions instead of one...]]></description>
		<content:encoded><![CDATA[<p>@all: Thanks for your comments!</p>
<p>@grigri: Yeah, moving the functionality to a behavior could make it more flexible. On the other hand I&#8217;m not sure whether such a flexibility is really necessary&#8230; Probably the approach mentioned by Jonah would be a good compromise. </p>
<p>@Jonah: Yes, that&#8217;s a good idea!</p>
<p>@ajmacaro: Yes, that&#8217;s probably the reason. Only, it doesn&#8217;t make it simpler, it makes it more &#8220;complex&#8221; because people now have to learn about two conventions instead of one&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ajmacaro</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111574</link>
		<dc:creator>ajmacaro</dc:creator>
		<pubDate>Wed, 29 Oct 2008 01:57:12 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111574</guid>
		<description><![CDATA[New baker&#039;s may use &quot;updated&quot; and some will use &quot;modified&quot;,
now, to make things simpler. the core decided.

&quot;Why dont we just support both? and lets move on to the
next problem. &quot;

Hmm, i just thought of that.

But hey, if theres a greater reason for this.  I just hope it
wasnt &quot;that&quot; complicated.]]></description>
		<content:encoded><![CDATA[<p>New baker&#8217;s may use &#8220;updated&#8221; and some will use &#8220;modified&#8221;,<br />
now, to make things simpler. the core decided.</p>
<p>&#8220;Why dont we just support both? and lets move on to the<br />
next problem. &#8221;</p>
<p>Hmm, i just thought of that.</p>
<p>But hey, if theres a greater reason for this.  I just hope it<br />
wasnt &#8220;that&#8221; complicated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rafaelbandeira3</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111569</link>
		<dc:creator>rafaelbandeira3</dc:creator>
		<pubDate>Wed, 29 Oct 2008 00:07:29 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111569</guid>
		<description><![CDATA[@grigri, Jonah, nateman: well it&#039;s definetly a good idea, but let&#039;s say that it&#039;s not that tough to make automagic filling fields, actually it&#039;s pretty easy, and you have all sort of things to make it happen be it by overriding some aside method (create, set, save...) or by simply using beforeSave and afterSave callbacks.

@cakebaker: strict conventions are much wiser, definetly right!]]></description>
		<content:encoded><![CDATA[<p>@grigri, Jonah, nateman: well it&#8217;s definetly a good idea, but let&#8217;s say that it&#8217;s not that tough to make automagic filling fields, actually it&#8217;s pretty easy, and you have all sort of things to make it happen be it by overriding some aside method (create, set, save&#8230;) or by simply using beforeSave and afterSave callbacks.</p>
<p>@cakebaker: strict conventions are much wiser, definetly right!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nateman</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111559</link>
		<dc:creator>nateman</dc:creator>
		<pubDate>Tue, 28 Oct 2008 21:43:30 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111559</guid>
		<description><![CDATA[@Jonah: That&#039;s exactly what I was about to suggest. This would be especially useful if you&#039;re porting an existing RoR or other app to Cake.]]></description>
		<content:encoded><![CDATA[<p>@Jonah: That&#8217;s exactly what I was about to suggest. This would be especially useful if you&#8217;re porting an existing RoR or other app to Cake.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonah</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111544</link>
		<dc:creator>Jonah</dc:creator>
		<pubDate>Tue, 28 Oct 2008 17:29:50 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111544</guid>
		<description><![CDATA[I would make sense to me if &quot;created&quot; and &quot;modified&quot; were used by default, but with an option to change them to anything else such as &quot;foo&quot; and &quot;bar&quot; within the model.]]></description>
		<content:encoded><![CDATA[<p>I would make sense to me if &#8220;created&#8221; and &#8220;modified&#8221; were used by default, but with an option to change them to anything else such as &#8220;foo&#8221; and &#8220;bar&#8221; within the model.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: grigri</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111541</link>
		<dc:creator>grigri</dc:creator>
		<pubDate>Tue, 28 Oct 2008 16:39:28 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111541</guid>
		<description><![CDATA[Perhaps it would be an idea for &#039;Bundt&#039; to move this behaviour to a built-in cakephp Behavior.

This would provide the option of choosing the field names, reducing overhead to models that don&#039;t need it, and providing a basic &#039;how-to&#039; example on automagic fields (browsing through libs/model.php is generally tough going... isolating the precise bits of code to perform this takes a while)]]></description>
		<content:encoded><![CDATA[<p>Perhaps it would be an idea for &#8216;Bundt&#8217; to move this behaviour to a built-in cakephp Behavior.</p>
<p>This would provide the option of choosing the field names, reducing overhead to models that don&#8217;t need it, and providing a basic &#8216;how-to&#8217; example on automagic fields (browsing through libs/model.php is generally tough going&#8230; isolating the precise bits of code to perform this takes a while)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cakebaker</title>
		<link>http://cakebaker.42dh.com/2008/10/28/updated-or-modified/comment-page-1/#comment-111537</link>
		<dc:creator>cakebaker</dc:creator>
		<pubDate>Tue, 28 Oct 2008 15:54:35 +0000</pubDate>
		<guid isPermaLink="false">http://cakebaker.42dh.com/?p=910#comment-111537</guid>
		<description><![CDATA[@all: Thanks for your comments!

@Henrik: I agree with you, it is not that logical to have a choice in that particular case. A convention like &quot;If you are interested in when a record was changed, add a column named &quot;x&quot; to your table and cake will update this column automagically when something is changed&quot; would be enough. 

@Tim: Well, even if you have (almost) no redundancy at the code level you still have redundant conventions. And this means you have to teach people two conventions instead of just one convention... 

@Arno: Yes, that would be a nice feature, but I doubt it will make it in the core. So you have to use something like the SoftDelete behavior mentioned by Hannibal.]]></description>
		<content:encoded><![CDATA[<p>@all: Thanks for your comments!</p>
<p>@Henrik: I agree with you, it is not that logical to have a choice in that particular case. A convention like &#8220;If you are interested in when a record was changed, add a column named &#8220;x&#8221; to your table and cake will update this column automagically when something is changed&#8221; would be enough. </p>
<p>@Tim: Well, even if you have (almost) no redundancy at the code level you still have redundant conventions. And this means you have to teach people two conventions instead of just one convention&#8230; </p>
<p>@Arno: Yes, that would be a nice feature, but I doubt it will make it in the core. So you have to use something like the SoftDelete behavior mentioned by Hannibal.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
