Является ли laravel created_at и updated_at инверсным?

Question

Laravel Framework версия 5.2.5

Когда я обновил запись, update_at не был изменен, а created_at был изменен на текущую временную метку.

Это правильно?

 
MariaDB [moon]> show columns from users; 
+----------------+------------------+------+-----+---------------------+-----------------------------+ 
| Field   | Type    | Null | Key | Default    | Extra      | 
+----------------+------------------+------+-----+---------------------+-----------------------------+ 
| id    | int(10) unsigned | NO | PRI | NULL    | auto_increment    | 
| name   | varchar(255)  | NO |  | NULL    |        | 
| email   | varchar(255)  | NO | UNI | NULL    |        | 
| password  | varchar(60)  | NO |  | NULL    |        | 
| remember_token | varchar(100)  | YES |  | NULL    |        | 
| created_at  | timestamp  | NO |  | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | 
| updated_at  | timestamp  | NO |  | 0000-00-00 00:00:00 |        | 
+----------------+------------------+------+-----+---------------------+-----------------------------+ 

<?php 

use Illuminate\Database\Schema\Blueprint; 
use Illuminate\Database\Migrations\Migration; 

class CreateUsersTable extends Migration 
{ 
    /** 
    * Run the migrations. 
    * 
    * @return void 
    */ 
    public function up() 
    { 
     Schema::create('users', function (Blueprint $table) { 
      $table->increments('id'); 
      $table->string('name'); 
      $table->string('email')->unique(); 
      $table->string('password', 60); 
      $table->rememberToken(); 
      $table->timestamps(); 
     }); 
    } 

    /** 
    * Reverse the migrations. 
    * 
    * @return void 
    */ 
    public function down() 
    { 
     Schema::drop('users'); 
    } 
} 

Answer 1

Глядя на вашу структуру базы данных проблема on update CURRENT_TIMESTAMP для created_at колонны. Это не должно быть очевидно. Глядя на миграцию, вряд ли эта миграция автоматически устанавливается автоматически, поэтому, вероятно, она была установлена ​​вручную в MySQL, поэтому вы должны удалить для столбца created_at.

Когда вы обновляете свою модель с помощью Eloquent updated_at, столбец должен быть обновлен без проблем (также в текущей схеме базы данных) - если это не вы, вероятно, не используете Eloquent, поэтому он не будет обновляться автоматически. Если вы не уверены, пожалуйста, покажите код, как вы обновите эту запись

Answer 2

Много людей имели этот вопрос в последнее время, и вы можете прочитать обсуждение на Github здесь: https://github.com/laravel/framework/issues/11518

MySQL 5.7 больше не допускает 0000-00-00 как действительную метку времени с включенным строгим режимом (что по умолчанию). Поэтому либо используйте ->nullableTimestamps(), либо ->timestamp()->useCurrent().

Вы можете это исправить, изменив следующим образом:

$table->timestamps(); 

Чтобы ни один из этих вариантов:

// Option 1: 
$table->nullableTimestamps(); 

// Option 2: 
$table->timestamp('updated_at')->useCurrent(); 
$table->timestamp('created_at')->useCurrent(); 

Кроме того, на этой странице MySQL: https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html

В качестве альтернативы , если explicit_defaults_for_timestamp отключен (по умолчанию), выполните одно из следующих действий: следующее:

Определите столбец с предложением DEFAULT, которое задает постоянное значение по умолчанию.

Укажите атрибут NULL. Это также приводит к тому, что столбец допускает значения NULL, что означает, что вы не можете назначить текущую временную метку, установив столбец в NULL. Назначение NULL устанавливает столбец в NULL.

В любом случае вышеуказанное решение должно решить вашу проблему.

Answer 3

Привет ребята меня зовут Arash laghaei из ирана я исправить эту проблему пожалуйста, сделайте это: поставщик/Laravel/рамки/СГД/освещения/базы данных/схемы/blueprint.php линия: +792

public function timestamps() 
{ 
    $this->timestamp('updated_at'); 

    $this->timestamp('created_at')->useCurrent(); 

} 

сделайте пожалуйста. и исправил эту проблему.