Comment puis-je définir la valeur par défaut d'une colonne timestamp à la valeur timestamp courante avec les migrations Laravel?

puisque c'est une expression brute, vous devez utiliser DB::raw() pour définir CURRENT_TIMESTAMP comme valeur par défaut pour une colonne:

$table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));

cela fonctionne parfaitement sur chaque pilote de base de données.

à partir de Laravel 5.1.25 (voir PR 10962 et commit 15c487fe ) vous pouvez utiliser la nouvelle méthode de modificateur de colonne useCurrent() pour définir la CURRENT_TIMESTAMP comme valeur par défaut pour une colonne:

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

comme demandé, sur MySQL vous pouvez également utiliser la clause ON UPDATE à travers DB::raw() :

$table->timestamp('updated_at')->default(DB::raw('CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP'));

Pièges

• MySQL
  
  
  
  à partir de MySQL 5.7, 0000-00-00 00:00:00 n'est plus considéré comme une date valide. Comme indiqué dans le Laravel 5.2 guide de mise à niveau , toutes les colonnes d'horodatage devraient recevoir une valeur par défaut valide lorsque vous insérez des enregistrements dans votre base de données. Vous pouvez utiliser le modificateur de colonne useCurrent() (à partir de Laravel 5.1.25 et ci-dessus) dans vos migrations pour utiliser par défaut les colonnes timestamp vers les horodateurs courants, ou vous pouvez utiliser les horodateurs nullable() pour autoriser les valeurs nulles.

• PostgreSQL & Laravel 4.x
  
  
  
  À Laravel 4.x versions, le Le pilote PostgreSQL utilisait la précision par défaut de la base de données pour stocker les valeurs d'horodatage. En utilisant la fonction CURRENT_TIMESTAMP sur une colonne avec une précision par défaut, PostgreSQL génère un timestamp avec la plus grande précision disponible, générant ainsi un timestamp avec une deuxième partie fractionnaire - voir ce violon SQL .

  cela conduirait Carbon à ne pas analyser une horodatage car il ne s'attend pas à ce que des microsecondes soient stockées. Pour éviter cet inattendu comportement de rupture de votre application vous devez explicitement donner une précision de zéro à la fonction CURRENT_TIMESTAMP comme ci-dessous:

  $table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP(0)'));
  

  depuis Laravel 5.0, les colonnes timestamp() ont été modifiées pour utiliser une précision par défaut de zéro qui évite cela.

  merci à @andrewhl pour avoir souligné cette question dans les commentaires.

pour créer à la fois les colonnes created_at et updated_at :

$t->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));
$t->timestamp('updated_at')->default(DB::raw('CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'));

vous aurez besoin de la version MySQL >= 5.6.5 pour avoir plusieurs colonnes avec CURRENT_TIMESTAMP

à partir de Laravel 5.1.26, étiqueté le 2015-12-02, un useCurrent() modificateur a été ajouté:

Schema::table('users', function ($table) {
    $table->timestamp('created')->useCurrent();
});

PR 10962 (suivi de commit 15c487fe ) conduit à cet ajout.

vous pouvez aussi lire les numéros 3602 et 11518 qui présentent un intérêt.

fondamentalement, MySQL 5.7 (avec la configuration par défaut) nécessite vous devez définir soit une valeur par défaut ou nullable pour les champs temporels.

Utilisation Paulo Freitas suggestion à la place.

Jusqu'à ce que Laravel corrige cela, vous pouvez lancer une requête de base de données standard après que le Schema::create ait été lancé.

    Schema::create("users", function($table){
        $table->increments('id');
        $table->string('email', 255);
        $table->string('given_name', 100);
        $table->string('family_name', 100);
        $table->timestamp('joined');
        $table->enum('gender', ['male', 'female', 'unisex'])->default('unisex');
        $table->string('timezone', 30)->default('UTC');
        $table->text('about');
    });
    DB::statement("ALTER TABLE ".DB::getTablePrefix()."users CHANGE joined joined TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL");

ça m'a fait des merveilles.

cela ne fonctionne pas pour un fait:

$table->timestamp('created_at')->default('CURRENT_TIMESTAMP');

il ne supprime pas le "0 par défaut" qui semble venir avec la sélection de timestamp et il ajoute juste le défaut personnalisé. Mais nous avons besoin sans les guillemets. Tout ce qui manipule un AD ne vient pas de Laravel4. C'est son point de vue. Il veut custom par défaut sur certaines colonnes comme:

$table->timestamps()->default('CURRENT_TIMESTAMP');

Je ne pense pas que ce soit possible avec Laravel. J'ai cherché pendant une heure maintenant, à voir si c'est possible.

Maj: Paulos Freita's answer montre que c'est possible, mais la syntaxe n'est pas simple.

Dans Laravel 5 simplement:

$table->timestamps(); //Adds created_at and updated_at columns.

Documentation: http://laravel.com/docs/5.1/migrations#creating-columns

C'est comme ça que tu le fais, j'ai vérifié et ça marche sur mon Laravel 4.2.

$table->timestamp('created_at')->default(DB::raw('CURRENT_TIMESTAMP'));

Espérons que cette aide.

Usethe suivant:

$table->timestamp('created_at')->nullable();

J'espère que ça vous aidera. Remercier.