Framework: Bug with $table->timestamps(); when overriding CREATED_AT and UPDATED_AT

[Xerotherm1c]

• Laravel Version: 5.7.*
• PHP Version: 7.1.3
• Database Driver: mysql

Description:

I've overridden the default timestamps in a single model. When I migrate:fresh my database and the table is recreated, $table->timestamps(); inside Schema::create() is not respecting the overridden timestamp column names. It should check if a model exists and if so, check for declared CREATED_AT and UPDATED_AT constants when running the migration.

[staudenmeir]

The migration doesn't and shouldn't know anything about the model. It's your responsibility to specify the custom timestamp columns.

[Xerotherm1c]

The migration doesn't and shouldn't know anything about the model. It's your responsibility to specify the custom timestamp columns.

Mind explaining why the migration should not know anything about the model? I'm relatively new to Laravel but I've seen a _lot_ of "behind the scenes" Laravel magic, and this feels like something that would be really nice icing on the cake.

Right now I'm using the following in my migration to reduce string literal redundancy of my column name overrides:

    $table->timestamp(AuthHistory::CREATED_AT)->useCurrent();
    $table->timestamp(AuthHistory::UPDATED_AT)->useCurrent();

@staudenmeir What is considered best practice in this instance if the above approach is not?

Thanks for your time.

[staudenmeir]

It's not recommended to have external dependencies like this in migrations. Migrations should always produce the same result, even if the surrounding application changes.

Consider a scenario where you decide to change the column name after a while. Now, your original migration suddenly creates a different table. This can cause all kinds of issues.

I would recommend you to just use strings.

$table->timestamp('my_custom_created_at')->useCurrent();
$table->timestamp('my_custom_updated_at')->useCurrent();

[driesvints]

Gonna close this as @staudenmeir explained the situation.

[Xerotherm1c]

@staudenmeir thank you for your explanation