Laravel changements created_at sur la mise à jour

Question

J'ai trouvé this answer sur le sujet, mais cela ne fonctionne pas pour moi.

Alors, je fais une entrée dans la base de données:

// Write lead to database 
$lead = Lead::create($lead_data); 

Et les horodatages ressemblent à cela, ce qui est bon:

| 2016-01-08 10:34:15 | 2016-01-08 10:34:15 | 

Mais je fais une demande à un serveur externe, et je dois mettre à jour la ligne:

$lead->user_id = $response['user_id']; 
$lead->broker_id = $response['broker_id']; 
$lead->save(); 

et le champ created_at obtient changé:

| 2016-01-08 04:34:17 | 2016-01-08 10:34:17 | 

Comment résoudre ce problème?

EDIT

je besoin d'une solution qui vient modifier le comportement sans suppression de colonnes ou remise à zéro des migrations. Le correctif doit être effectué sur une base de données en direct sans toucher aux données. Comme suggéré ci-dessous, j'ai essayé la migration suivante:

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

mais rien ne se passe. Le champ created_at est toujours modifié lors de la mise à jour.

Answer 1

Si vous utilisez Laravel 5.2 et que vous utilisez MySQL, il y a eu un "bug" introduit avec les horodatages. Vous pouvez lire tout sur le problème sur github here. Cela concerne les valeurs par défaut de l'horodatage, et MySQL attribue automatiquement les attributs DEFAULT CURRENT_TIMESTAMP ou ON UPDATE CURRENT_TIMESTAMP sous certaines conditions.

Fondamentalement, vous avez trois options.

1. Mise à jour variables MySQL:

Si vous définissez la variable explicit_defaults_for_timestamp-TRUE, aucune colonne d'horodatage sera attribué CURRENT_TIMESTAMP DEFAULT ou ON UPDATE CURRENT_TIMESTAMP attribue automatiquement. Vous pouvez en savoir plus sur la variable here.

2. Utilisez horodatages nullables:

Changer $table->timestamps()-$table->nullableTimestamps(). Par défaut, la commande $table->timestamps() crée des champs d'horodatage qui ne sont pas valables. En utilisant $table->nullableTimestamps(), vos champs d'horodatage seront nullables, et MySQL n'attribuera pas automatiquement le premier les attributs DEFAULT CURRENT_TIMESTAMP ou ON UPDATE CURRENT_TIMESTAMP.

3. Définir les horodatages vous:

Au lieu d'utiliser $table->timestamps, utilisez-vous $table->timestamp('updated_at'); $table->timestamp('created_at');. Assurez-vous que votre champ 'updated_at' est le premier horodatage de la table, de sorte que ce soit celui qui attribue automatiquement les attributs DEFAULT CURRENT_TIMESTAMP ou ON UPDATE CURRENT_TIMESTAMP.

Answer 2

Skatch - Je pense que votre solution ci-dessus n'est pas tout à fait raison, mais est très bien dans ce cas.

Le problème est que vous obtenez la date PHP, pas l'horodatage MYSQL par défaut pour votre valeur par défaut. Lorsque vous exécutez cette migration, vous obtenez une instruction comme celle-ci:

alter table alter column created_at default '2016:02:01 12:00:00'; 

Notez la chaîne pour votre date. Lorsque vous exécutez votre migration, cette date sera toujours utilisée pour votre created_at, et non la date actuelle lorsqu'un enregistrement est ajouté plusieurs jours plus tard. Au lieu de faire "date ('Y: m: d H: i: s')", vous pouvez faire DB :: raw ('current_timestamp') pour résoudre ce problème.

(SRY, ne pouvait pas simplement ajouter un commentaire ci-dessus - ma réputation est pas assez élevé encore ...)

Answer 3

ce détachement comme une réponse de haut niveau, résumant notre discussion de commentaires. D'abord, il y a une date bug introduite dans Laravel - comme noté par @patricus. Les solutions suggérées dans la discussion de bogue sont d'utiliser nullableTimestamps() au lieu de simplement timestamps(), ou de créer les champs created_at et updated_at directement - $table->timestamp('updated_at')->change().

Cela peut également être corrigé avec SQL brut. Une déclaration similaire à ce ALTER

alter table loader_rawvalues MODIFY column updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 

qui peut être appliqué directement sur vos tables de DB existantes (Testez d'abord, ou bien sûr!). OU vous pouvez utiliser DB :: unprepared() pour l'appliquer depuis votre migration, par exemple:

class CreateMyTable extends Migration 
{ 
    public function up() 
    { 
     Schema::create('mytable', function (Blueprint $table) { 
      $table->bigIncrements('id'); 
      // ... 
      $table->timestamps(); 
     }); 

     DB::unprepared('alter table mytable MODIFY column updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP'); 
    } 
}