Framework: Allow only create_at or updated_at

[rentalhost]

Currently Laravel forces users to use Blueprint::timestamps() to create created_at and updated_at (or disable both). If user need only of created_at or updated_at, they will need hardcode it.

Suggestion is allow define separately this behaviours.

Example:

class User extends Model
{
    public $timestamps = false; // disable all behaviour
    public $timestamps = true; // enable all behaviour
    public $timestamps = [ "created_at" ]; // enable only to created_at
    public $timestamps = [ "updated_at" ]; // enable only to updated_at
    public $timestamps = [ "created_at", "updated_at" ]; // same that true
}

It'll not cause break-changing, I guess.

[BeingTomGreen]

If you're talking about dates on a model, you can override the getDates method like so:

class User extends Model
{
    public function getDates()
    {
        return ['created_at', 'expire_date'];
    }
}

Helpfully Laravel will automatically convert expire_date to Carbon object, just like it normally does with created_at and updated_at.

To disable timestamps completely you can just use public $timestamps = false;.

[GrahamCampbell]

If you're talking about dates on a model, you can override the getDates method like so:

No, "timestamps" are unrelated to that.

[absolux]

To disable only updated_at column, i tried to override only

public function setUpdatedAt($value) {
    // Do nothing.
}

but,

public function getUpdatedAtColumn() {
    return null;
}

should be overridden, because Laravel is processing updated_at twice

• in performUpdate with $this->updateTimestamps()
• and then later in Builder with $this->addUpdatedAtColumn($values).

more details on stackoverflow

[rentalhost]

Exactly. Here I created a trait that override two methods setUpdateAt($value) returning null, and usesTimestamps() returning false (it'll help with the Builder issue).

[rentalhost]

@GrahamCampbell Can you explain the reason to close this FR? Thanks.

[GrahamCampbell]

Because you provided a solution, and we don't process proposal issues anyway.

[rentalhost]

This solution is a workaround of a thing that I suppose to be native. One time that Laravel support both features, but only together. And on real life, it can be more than the need. For instance, I don't need update_at on a change log table. Only created_at. Solution is very simple and not is a break change.

But if I pull request it can be availed better, or is a "full closed case"?

[GrahamCampbell]

Yeh, I'm not closing is to say don't talk about it again. I'm just moving it off our immediate todo list.

All proposals need to be discussed over a pull request, or directly with Taylor.

[mpyw]

Solution here: https://github.com/laravel/framework/pull/19139#issuecomment-300698303