Remplissage d'une base de données dans un Laravel fichier de migration

Je suis en train d'apprendre Laravel, et disposer d'un fichier de migration de la création d'une table des utilisateurs. Je suis en train de remplir un enregistrement de l'utilisateur dans le cadre de la migration:

public function up()
{
    Schema::create('users', function($table){

        $table->increments('id');
        $table->string('email', 255);
        $table->string('password', 64);
        $table->boolean('verified');
        $table->string('token', 255);
        $table->timestamps();

        DB::table('users')->insert(
            array(
                'email' => '[email protected]',
                'verified' => true
            )
        );

    });
}

Mais j'obtiens l'erreur suivante lors de l'exécution de php artisan migrate:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'vantage.users' doesn't exist

C'est évidemment parce que l'Artisan n'a pas encore créé de la table, mais l'ensemble de la documentation semble dire qu'il existe un moyen d'utiliser Couramment Requête pour remplir données dans le cadre d'une migration.

Ce que quelqu'un sait comment faire? Merci!

InformationsquelleAutor Adam Hopkinson | 2012-10-04

183

Ne pas mettre la DB::insert() à l'intérieur du Schéma::create(), parce que la méthode create a à la fin de la création de la table avant que vous pouvez insérer des trucs. Essayez plutôt ceci:

public function up()
{
    //Create the table
    Schema::create('users', function($table){
        $table->increments('id');
        $table->string('email', 255);
        $table->string('password', 64);
        $table->boolean('verified');
        $table->string('token', 255);
        $table->timestamps();
    });

    //Insert some stuff
    DB::table('users')->insert(
        array(
            'email' => '[email protected]',
            'verified' => true
        )
    );
}

Merci Benjamin, c'est excellent!
et comment insérer des données multiples ?
je pense que quelque chose comme ce DB::table('users')->insert([ ['email' => '[email protected]', 'votes' => 0], ['email' => '[email protected]', 'votes' => 0] ]);

InformationsquelleAutor BenjaminRH

69

Je sais que c'est un vieux post mais depuis il est livré dans une recherche google, je pensais que je voudrais partager quelques connaissances ici. @erin-geyer a souligné que le mélange des migrations et de semoirs peut créer des maux de tête et @justamartin répliqué que parfois vous voulez/besoin de données pour être peuplée que la partie de votre déploiement.

J'irais plus loin et dire que, parfois, il est souhaitable d'être en mesure de déployer les modifications des données de façon constante, de sorte que vous pouvez, par exemple, de déployer à la mise en scène, de voir que tout est bien, et puis de déployer en production avec la confiance des mêmes résultats (et ne pas avoir à se rappeler pour exécuter une étape manuelle).

Cependant, il ya encore de la valeur en séparant les graines et la migration comme les deux liés, mais distincts des préoccupations. Notre équipe a compromise par la création des migrations qui appel de semoirs. Cela ressemble à:
```
public function up()
{
    Artisan::call( 'db:seed', [
        '--class' => 'SomeSeeder',
        '--force' => true ]
    );
}
```
Ce qui permet d'exécuter une graine une fois tout comme une migration. Vous pouvez également mettre en place une logique qui empêche ou augmente comportement. Par exemple:
```
public function up()
{
    if ( SomeModel::count() < 10 )
    {
        Artisan::call( 'db:seed', [
            '--class' => 'SomeSeeder',
            '--force' => true ]
        );
    }
}
```
Ce serait évidemment conditionnellement de l'exécution de vos seeder s'il y a moins de 10 SomeModels. Ceci est utile si vous souhaitez inclure le semoir comme un standard de semoir qui a exécuté lorsque vous appelez artisan db:seed ainsi que lors de la migration, de sorte que vous n'avez pas "double-up". Vous pouvez aussi créer un revers de semoirs, de sorte que les restaurations fonctionne comme prévu, par exemple,
```
public function down()
{
    Artisan::call( 'db:seed', [
        '--class' => 'ReverseSomeSeeder',
        '--force' => true ]
    );
}
```
Le deuxième paramètre --force est nécessaire pour permettre à seeder pour s'exécuter dans un environnement de production.
- C'est de loin la meilleure réponse. Facile à gérer le code qui sépare les préoccupations!
- Je serais prudent de considérer les implications à long terme de l'appel de semoirs à partir de scripts de migration. Les scripts de migration sont de date/heure numéro de version, tandis que les semoirs sont généralement pas. Au cours du développement, semoir a souvent besoin de changer, entraînant la possibilité des versions des scripts de migration en cours d'exécution non versionnées semoirs -- rupture idempotence. En d'autres termes, l'ensemble de scripts de migration de jour en jour, pourrait donner des résultats différents.
- Il a été un moment depuis que j'ai posté ce sujet et je voulais offrir notre expérience de l'utilisation de cette technique. Dans l'ensemble il a bien fonctionné pour nous, et si je devais tout recommencer, je le ferais. Cela dit il y a une chasse aux sorcières à être conscient de. @originalbryan est exactement droit et la conséquence en est que nous avons l'occasion de rencontrer des situations où les migrations de pause lorsqu'on fait tourner une nouvelle DB, parce que les migrations exécuter le semoir (et le modèle) sont plus à jour de la base de données (puisque l'on peut semences avant le schéma est entièrement mis à jour). Lorsque cela se produit, nous mettons à jour les anciennes migrations pour répondre à la question.
- J'entends que ce n'est pas une bonne pratique pour mettre à jour les anciens fichiers de migration - au lieu de mettre à jour les anciens fichiers, vous devez créer un nouveau fichier de migration - c'est le "flux de travail" pour les fichiers de migration par la conception
- l'utilisation de ce modèle, il est parfois inévitable. Imaginez que vous avez une migration qui crée un tableau avec deux colonnes puis il appelle un semoir de semis à l'aide d'un modèle pour remplir le tableau. Ensuite, vous créez une nouvelle migration d'ajouter une troisième colonne et de mettre à jour le modèle. Maintenant, le semoir se déroulera entre la première et la deuxième migration et de remplir erreur fatale parce qu'il essaie d'insérer des enregistrements avec trois colonnes lorsque seulement deux existent (la deuxième migration n'a pas exécuté encore). Pour cette raison, nous avons parfois à mettre à jour les anciennes migrations.
- oui, votre proposition de briser cette règle. Si nous appelez pas semoir à l'intérieur de la migration de fichier, mais mettre "INSÉRER-s' directement dans le fichier de migration puis nous avons sauvé de la cohérence des données sans modification des anciens fichiers de migration. En fait, j'ai clairement ne pas voir le problème avec la mise en INSÉRER dans les fichiers de migration - par exemple, j'ai le système avec 30 tables, et souhaitez ajouter une nouvelle fonctionnalité qui ont besoin d'une nouvelle table avec des données initiales - alors je l'ai mis initiale des données dans le fichier de migration (dans la méthode séparée) - pas de problème 😛
- Je pense que c'est un bon compromis pour toujours ajouter de nouveaux semoirs et leur version électronique.g 20181215SomeSeeder et il suffit de faire une règle qui semoirs n'avez pas mis à jour tout comme les migrations.
InformationsquelleAutor darrylkuhn
11

Ici est une très bonne explication de pourquoi à l'aide de Laravel Base de données du Semoir est préférable à l'utilisation des Migrations: http://laravelbook.com/laravel-database-seeding/

Bien que, suivant les instructions de la documentation officielle est une bien meilleure idée, parce que la mise en œuvre décrite dans le lien ci-dessus ne semble pas fonctionner et est incomplète. http://laravel.com/docs/migrations#database-seeding
- Je suis d'accord avec vous Erin. Ne pas mélanger des migrations avec des graines de données, car il est très probable que vous aimeriez semences de certaines données dans votre environnement de développement, mais pas dans votre environnement de production.
- Bon point, mais il y a certaines situations où certaines données doivent exister dans un environnement de production. Par exemple, le premier utilisateur admin par défaut doit exister afin que le client peut se connecter pour la première fois, quelques preset rôles d'autorisation doit exister, certains la logique de gestion de données pourrait également être nécessaire immédiatement. Donc, je pense que les données obligatoires doivent être ajoutés pour les migrations (de sorte que vous pouvez haut/bas aussi des enregistrements de données par le biais des migrations distinctes), mais les graines peuvent être de gauche pour le développement.
- Une petite remarque: le lien vers la base de données de semis est maintenant: laravel.com/docs/5.3/seeding
InformationsquelleAutor Erin Geyer
2

Cela devrait faire ce que vous voulez.
```
public function up()
{
    DB::table('user')->insert(array('username'=>'dude', 'password'=>'z19pers!'));
}
```
- Merci @strings28, mais avez-vous vu que j'avais déjà accepté une semblable réponse un mois en arrière?
- Apparemment je n'ai pas désolé 🙂
InformationsquelleAutor strings28

Un autre moyen propre à faire est de définir une méthode privée qui créer l'instance et persistent concernées de Modèle.

public function up()
{
    Schema::create('roles', function (Blueprint $table) {
        $table->increments('id');
        $table->string('label', 256);
        $table->timestamps();
        $table->softDeletes();
    });

    $this->postCreate('admin', 'user');
}

private function postCreate(string ...$roles)  {
    foreach ($roles as $role) {
        $model = new Role();
        $model->setAttribute('label', $role);
        $model->save();
    }
}

Avec cette solution, les horodateurs, les champs seront générés par Éloquent.

EDIT:
il est préférable d'utiliser un semoir système de disctinct structure de base de données et de génération de la base de données de la population.

Super, j'ai bien aimé votre approche. Merci

InformationsquelleAutor Maximilien DI DIO

-12

essayer: (pas testé)

public function up()
{
    Schema::table('users', function($table){

        $table->increments('id');
        $table->string('email', 255);
        $table->string('password', 64);
        $table->boolean('verified');
        $table->string('token', 255);
        $table->timestamps();

        $table->insert(
            array(
                'email' => '[email protected]',
                'verified' => true
            )
        );

    });
}

Merci @aowie1 - j'avais déjà essayé ça, mais des erreurs parce que Table::insert() n'est pas une méthode valable

InformationsquelleAutor aowie1

Vous devez vous connecter pour publier un commentaire.