Hello.
New feature request for 4.x.x
I suggest to write the following methods for the class \Phalcon\Mvc\Model:
1.
public function enableTheSupportOfCreatedAtField()
{
$this->addBehavior(
new \Phalcon\Mvc\Model\Behavior\Timestampable(
[
'beforeCreate' => [
'field' => 'created_at',
'format' => 'Y-m-d H:i:s'
]
]
)
);
}
2.
public function enableTheSupportOfUpdatedAtField()
{
$this->addBehavior(
new \Phalcon\Mvc\Model\Behavior\Timestampable(
[
'beforeCreate' => [
'field' => 'updated_at',
'format' => 'Y-m-d H:i:s'
]
]
)
);
}
I think it's very actually things =)
To be honest i don't like this. It should be handled by developer, some are using timestamps created by database, some doesn't need this at all.
What we could do is some trait in incubator(isn't there already thing like this?), but nothing more is needed imho.
@Jurigag Too bad, uh, I thought those were really necessary buns(
@Jurigag It's a shame, looking at Eloquent to understand and realize that this will not be in Phalcon ORM )
I love the enthusiasm and trying to make the framework better. However we need to always keep a good balance between performance and features.
If we start to add more and more things to the model, which is one of the heavy/big classes of the framework, performance will degrade.
I am not saying that this feature is not helpful but consider this:
When you start creating your application, you also start writing models to interact with your database. The more features you build the more you might change the models. But after the initial programming effort your models do not change that much.
Moving this code (which is easily added in the initialize of any model you need - or not)
<?php
use Phalcon\Mvc\Model;
use Phalcon\Mvc\Model\Behavior\Timestampable;
class Users extends Model
{
public $id;
public $name;
public $created_at;
public function initialize()
{
$this->addBehavior(
new Timestampable(
[
'beforeCreate' => [
'field' => 'created_at',
'format' => 'Y-m-d',
]
]
)
);
}
}
to a method that is restricted to a particular field will increase the size of the model and will not always used by everyone - for all their needs. Not everyone uses a field called _created_at_ or _updated_at_. Some people might need the same functionality but use _createdAt_ or _updatedAt_
One could argue that you can set the field that is the "updatable" or "creatable" one in the model setup/initialize. If that is the case then you can easily add the behavior as shown above to any model you need to.
Nay on this from me. It's too project-specific and actually very easy to implement for those who need it :)
Agree with the others and recommend that it be handled by the developer to implement. I often use PostgreSQL which includes time zone information in its stamps and this would not account for that.
Most helpful comment
I love the enthusiasm and trying to make the framework better. However we need to always keep a good balance between performance and features.
If we start to add more and more things to the model, which is one of the heavy/big classes of the framework, performance will degrade.
I am not saying that this feature is not helpful but consider this:
When you start creating your application, you also start writing models to interact with your database. The more features you build the more you might change the models. But after the initial programming effort your models do not change that much.
Moving this code (which is easily added in the
initializeof any model you need - or not)to a method that is restricted to a particular field will increase the size of the model and will not always used by everyone - for all their needs. Not everyone uses a field called _created_at_ or _updated_at_. Some people might need the same functionality but use _createdAt_ or _updatedAt_
One could argue that you can set the field that is the "updatable" or "creatable" one in the model setup/initialize. If that is the case then you can easily add the behavior as shown above to any model you need to.