Bug Report #826
ORM behavior: Timestampable
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: |  John Heathco |
% Done: | 100% |
|
| Category: | Libraries:ORM | |||
| Target version: | 2.4 | |||
| Resolution: | fixed | Points: |
Description
Take a look at http://www.doctrine-project.org/documentation/manual/1_0?chapter=behaviors#core-behaviors:timestampable for reference.
If there is the column created_at the ORM class should insert the timestamp when inserting a new row to the table.
If there is the column updated_at the ORM class should update it every time the row is modified.
I think ill do a path myself when i get some time, only the save or set method should change and 2 class attributes should be added for the names of the columns.
History
Updated by Kyle - over 3 years ago
I don't think this is necessary for the ORM. But you can easily add it to your own by extending the ORM class. I have done something pretty similar in my own ORM which extends the current.
Updated by Woody Gilk over 3 years ago
This doesn't really belong in ORM because it makes an assumption about column names. This might be a useful feature, but I'll have to think about it more.
If only PHP supported aggregate objects....
Updated by new car - over 3 years ago
Replying to [comment:2 Shadowhand]:
This doesn't really belong in ORM because it makes an assumption about column names. This might be a useful feature, but I'll have to think about it more.
If only PHP supported aggregate objects....
I dont know if you intent to let ORM small or what, but i dont see why its a problem to put something like this behavior on the ORM class. A lot of ORM libs/classes do this, se for example Akelos Active Record implementation: http://www.akelos.org/xref/nav.html?AkActiveRecord.php.html
I dont know if the best way is to put this kind of feature direct into the ORM class, but i think there is no problem, only if you are worried about it becoming too bloated.
Thx for the replay so far. =)
Updated by Woody Gilk over 3 years ago
The point is that it forces something specific on ORM (columns named created_at, updated_at) which is what I am trying to avoid. A solution that is user-defined, or even a convention that can be overloaded by the user, would make this potentially accepted.
Updated by new car - over 3 years ago
Replying to [comment:4 Shadowhand]:
The point is that it forces something specific on ORM (columns named created_at, updated_at) which is what I am trying to avoid. A solution that is user-defined, or even a convention that can be overloaded by the user, would make this potentially accepted.
Yes, that is what im suggesting. A convention. That columns name could be changed or this behavior could be disabled at all.
Updated by Sam de Freyssinet about 3 years ago
If this were to be implemented, the columns should be defined in a similar way to current properties such as ORM::$primary_key or ORM::$primary_value.
Updated by John Heathco over 2 years ago
- Status changed from New to Closed
- Assignee changed from Woody Gilk to John Heathco
- % Done changed from 0 to 100
- Resolution set to fixed
- 11 set to 2.3.4
This has been implemented. Two fields, $updated_column and $created_column have been added that default to NULL (which ignores them). To use them, define in the following format:
protected $updated_column = array('column' => 'last_updated', 'format' => 'm-D-Y');
The 'format' must be compatible with the date() method. TRUE may be used for a Unix timestamp (or 'U')