I'm currently writing a module that requires knowing when various things were created (things that we don't necessarily know about ahead of time). That basically involves guessing the column / object key where the created time is stored. Almost universally across core and other modules, "created" is used for the timestamp things were created and "timestamp" is used for more ambiguous times (such as if the same column keeps track of both the time the entity was created and changed). Additionally "changed" is used in core and usually in contrib for the column representing the timestamp when an entity was updated. Personally I much prefer "last_updated" or simply "updated" over "changed," but I don't choose these things. Also I care a lot less about that column because it doesn't particularly affect what I'm doing. :-P
Anyway, the reason I'm bringing this up is because in order to get the timestamp I currently have to do this:
function EXAMPLE_get_timestamp($data) {
// Practically everything uses either "timestamp" or "created." User Relationships uses created_at and Userpoints uses time_stamp.
foreach (array('timestamp', 'created', 'created_at', 'time_stamp') as $key) {
if (isset($data->$key)) {
return $data->$key;
}
}
// If we don't find anything, return the current time. This will be accurate except when reading existing data.
return time();
}
Here is what I would like to do instead:
return (isset($data->timestamp) ? $data->timestamp : (isset($data->created) ? $data->created : time()));
My preference for ternary syntax aside, I believe there is an argument to be made for consistency, especially consistency with core. I don't really expect this to happen in a stable branch, but 7.x-1.x is still in alpha... ;-) Something to keep in mind for future branches anyway.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | ur-standardize-date-columns-1230790.patch | 8.51 KB | icecreamyou |
| #4 | ur-standardize-date-columns-1230790.patch | 8.51 KB | icecreamyou |
| #2 | ur-standardize-date-columns-1230790.patch | 7.82 KB | icecreamyou |
Comments
Comment #1
berdirI'd be ok with this change if you can provide a patch... :)
Comment #2
icecreamyou commentedSure.
To create this patch I ran:
Comment #3
berdirNote that grep won't write the update function for you ;)
Let's see what the tests say...
Comment #4
icecreamyou commentedOh, right. Well, boo. It should. :-P
Here's a version with an update function.
Comment #5
berdirTrailing spaces after changed/created.
Note that there are also indexes on these columns which must be dropped before the rename and re-added again (db_change_field as a $new_keys argument..) as explained on http://api.drupal.org/api/drupal/includes--database--database.inc/functi....
Comment #6
icecreamyou commentedNone that I can see. The schema for {user_relationships} looks like this:
No indexes on created/changed there.
Attached patch with whitespace fixes.
Comment #7
berdirYou are correct, my mistake.
Comment #8
berdirThanks for the patch, commited and pushed!