Comments on: “updated” or “modified”

By: cakebaker

cakebaker — Thu, 30 Oct 2008 16:05:14 +0000

@all: Thanks for your comments!

@grigri: Yeah, moving the functionality to a behavior could make it more flexible. On the other hand I’m not sure whether such a flexibility is really necessary… Probably the approach mentioned by Jonah would be a good compromise.

@Jonah: Yes, that’s a good idea!

@ajmacaro: Yes, that’s probably the reason. Only, it doesn’t make it simpler, it makes it more “complex” because people now have to learn about two conventions instead of one…

By: ajmacaro

ajmacaro — Wed, 29 Oct 2008 01:57:12 +0000

New baker’s may use “updated” and some will use “modified”,
now, to make things simpler. the core decided.

“Why dont we just support both? and lets move on to the
next problem. ”

Hmm, i just thought of that.

But hey, if theres a greater reason for this. I just hope it
wasnt “that” complicated.

By: rafaelbandeira3

rafaelbandeira3 — Wed, 29 Oct 2008 00:07:29 +0000

@grigri, Jonah, nateman: well it’s definetly a good idea, but let’s say that it’s not that tough to make automagic filling fields, actually it’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!

By: nateman

nateman — Tue, 28 Oct 2008 21:43:30 +0000

@Jonah: That’s exactly what I was about to suggest. This would be especially useful if you’re porting an existing RoR or other app to Cake.

By: Jonah

Jonah — Tue, 28 Oct 2008 17:29:50 +0000

I would make sense to me if “created” and “modified” were used by default, but with an option to change them to anything else such as “foo” and “bar” within the model.

By: grigri

grigri — Tue, 28 Oct 2008 16:39:28 +0000

Perhaps it would be an idea for ‘Bundt’ 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’t need it, and providing a basic ‘how-to’ 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)

By: cakebaker

cakebaker — Tue, 28 Oct 2008 15:54:35 +0000

@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 “If you are interested in when a record was changed, add a column named “x” to your table and cake will update this column automagically when something is changed” 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.

By: dr. Hannibal Lecter

dr. Hannibal Lecter — Tue, 28 Oct 2008 15:04:09 +0000

Arno,

what you’re looking for is SoftDeletable behavior:

http://bakery.cakephp.org/articles/view/soft-delete-behavior

By: Arno E

Arno E — Tue, 28 Oct 2008 14:03:18 +0000

What I would like, however, is a “deleted” column with a default value of “null” that gets updated on delete. By default, only fields with a “deleted” value of “null” gets returned. This way we can have non-destructive deletes for accountability practices.

By: Tim Koschuetzki

Tim Koschuetzki — Tue, 28 Oct 2008 11:01:02 +0000

@Daniel: I second your opinion.

@Henrik: It’s a naming preference, nothing not conventional. After all it doesn’t add much code to the framework (and thereby redundance) to support both.