Q&A
タイポ時のマイグレートはエラーが出ずに通ったのだと思いますが、unsingedはuser_idについていますか？
up関数のところで、
$table->integer('user_id')->unsinged()->index();
unsignedと書かないといけないところを、上記のようにスペルをタイポし、マイグレートしてしまっています。
また、外部キー制約として
PHP
1$table->foreign('user_id')->references('id')->on('users');
こちらの記述も追加したいです。
以上の2点を新たにマイグレーションファイルを作る際、up関数とdown関数にはそれぞれどのように記述すればいいか、およびマイグレーションファイル名はどのように名付ければいいか、それぞれ教えていただけませんでしょうか？m(_ _)m
よろしくお願いいたします。
ご回答ありがとうございます。
いえ、付いていないようです。
https://gyazo.com/c616ede95359cce10abc9e5c9fb6b4b2
すみません、勘違いしておりました。
そのばあいなら、unsignedは無視して、記述してよいと思います。
いただいたURLを確認すると、「MySQLのみ」となっていますね。
ただ、「id」カラムには自動的に（？）unsignedが付いていますが、これはこういうものなんでしょうか？
MariaDBにカラム修飾子「unsigned()」が使えない場合、代替できるものはありますか？
また、その際のup関数とdown関数への書き方、マイグレーションファイル名の名付け方、外部キー制約を追加する場合についてもアドバイスをいただけると幸いですm(_ _)m
MySQLとMariaDBの違いについて調べてみたところ、このようなことが書かれていました。
MySQLとMariaDBでは、利用出来るコマンドについてもほとんど同じと考えて問題ありません。
全てのコマンドを調査したわけではないため全く同じとは言えませんが、少なくとも高度なデータベース操作ではなく、一般的に利用されるSQLコマンドの範囲では違和感なくMySQLとMariaDBどちらも同じように使用することが可能です。
https://style.potepan.com/articles/19653.html
ですが、リファレンスに書かれてあるとおり、unsignedはMySQLでしか使えないということなんでしょうかね・・・とりあえず、上の記事に希望を持って、MariaDBでも試してみたいと思います。
とりあえず、自分なりに下記のように命名してマイグレーションファイルを作り、マイグレートしてみました。
add_unsigned_and_index_to_user_id_to_lectures_table
しかし、このようなエラーが出ました。
https://gyazo.com/ce1361c5c7caf623e29633731833534d
（up関数とdown関数の記述内容もこちらのURLから確認できます）
すでに「user_id」というカラムが存在するからNGというエラーなんでしょうが、既存のカラムに、今回のようにカラム修飾子を追加してマイグレーションファイルを作成する際のup関数とdown関数のところの書き方がわかりません。
いろいろと調べてみたのですが、その書き方が参考になるページを見つけられませんでした。
また、外部キー制約を記述する際も同様に、up関数とdown関数への書き方はどうなりますでしょうか？
「upに書いて、downには書かない」ということになるんでしょうか？
回答1件
0
ベストアンサー
mariadbについては、私もあまり知識がないので、なんともいえないです。
マイグレーションファイルには、テーブルを書き換えるという役割（upの部分）とその書き換えを元の状態に戻すロールバッグという役割（down）があります。
今回新規にマイグレーションファイルを追加して、DB構造を変えるなら、既存のuser_idを削除してから、user_idを加える処理を書く必要があります。それに加えて、外部キー制約をつけます。(down側ではそれらを戻す処理)
投稿2020/04/29 13:25
総合スコア1135
ありがとうございますm(_ _)m
なるほど、一度「user_id」を削除するマイグレーションファイルを作り、もう一度加えるマイグレーションファイルを作る際、外部キー制約を書けばいいということですね。
ただ、down関数に書く際、「user_id」を削除する処理を書くのはわかるのですが、外部キー制約については削除する処理の書き方はどうなるのでしょうか？
それでもいいですが、削除と加えるものを同じファイルで行なってもよいですよ。先に削除処理を記述して、その下に加える処理を書くとできます。
dropForeignというのがあります。
ドキュメントの外部キー制約の部分に書いてあるので見てみてください。
ありがとうございます。
怖いので、ひとつずつ試してみました。
とりあえず、テーブル内のカラムはこんな感じになり、「user_id」に「unsigned」を付けることもできました。
https://gyazo.com/c2626070a76bc14e555d89c7c3d7dfdf
これであとは外部キー制約の処理をするだけなんですが、これがどうもうまくいきません。
https://gyazo.com/bf3045cf3582c6084526b01719cdd6ce
調べてみたのですが、このエラーに対する情報量が乏しく、打開策が見出だせない状況です。
何かわかりますでしょうか？m(_ _)m
テーブル構造はこのようになっています。
users テーブル
https://gyazo.com/831e6d98dfc12e266db09b3a0db6bd11
lectures テーブル
https://gyazo.com/c2626070a76bc14e555d89c7c3d7dfdf
外部キー制約を変更する場合、upの中で、まず外して、次につけるという流れになります。
$table->dropForeign('lectures_user_id_foreign'); // 既存の外部キー制約を外す。
$table->foreign('user_id')->references('id')->on('users'); // 新しい外部キー制約をつける
そして、downには、反対に新しくつけた外部キー制約を外し、元の外部キー制約をつける処理を書きます。
downとは、php artisan migrate:rollbackというコマンドを実行した際に処理がおこなわれる処理のことです。(つまり、downの処理は、php artisan migrateした時点では実行されません。)
マイグレーションのページを一度全て読んでみると、どういう仕組みなのかを理解できるかと思います。
https://readouble.com/laravel/5.5/ja/migrations.html
元々、外部キー制約を付けていなかったので、今回初めて付けようと思った次第ですね????
それで、「dropForeign」メソッドの書き方を調べ、見よう見マネで書いてみて起こったエラーです。
なので、そもそも「既存の外部キー制約」というものがない状態なんですが、その場合ってどうすればいいでしょうか？
up関数とdown関数の処理について、大方のことは把握しているつもりなんですが、記述するメソッドによったり、今回のように外部キー制約を付けるにあたっての書き方については不透明なところがあります・・・。
もう一度、最初からカラムを作り直したほうがいいでしょうかね？
途中でカラムを消したり追加したりしていて、不意にマイグレーションファイル自体を手動で削除してしまったりもしているので・・・。
もう一度、イチからカラムを定義し直そうとする場合、「php artisan migrate:fresh」を行い、--create=table名でテーブルを作ればよいでしょうか？
その際には忘れず、外部キー制約を施したいと思います。
すみません、そうだったんですね。すでに制約がついていると、勘違いしておりました。
私自身、まだまだ書き方が不明瞭なことはよくあります。そんなときはドキュメントをとりあえずみるようにして、それでもダメならGoogle検索、最終手段でコードを読むというような感じです。
消したりしているならその方がよいかもしれません。
「php artisan migrate:fresh」を行うと、一度全てのテーブルが削除され、それからマイグレーションファイル を元にテーブルが作成されます(この部分は「php artisan migrate」と同じ内容です)。
（本来は、アンチパターンだと思います。マイグレーションファイルを削除することなく、追加していくことで他の人が、「php artisan migrate」を実行するだけで最新の環境を用意できるようというのが、マイグレーションファイルの利点だと思うので。個人の場合、マイグレーションファイルの削除はそれほど気にする必要はありませんが、チーム開発だと注意が必要です。）
ありがとうございます(・∀・)
こちらでもいろいろ調べてみて、すでに入ってあるデータの外部キーを付けたいカラムとその外部カラムの値が、なぜか一致していないことに気づき、ひとまずデータをすべて消してみました。
その上で、外部キー制約の処理の記述を追加したマイグレーションファイルをマイグレートしてみたところ、エラーが出ずにマイグレートできました。
ただ、本当にこれで外部キー制約の処理が正しく行われたのかどうか、カラム構造を確認してもわからなかったので、一度、ダミーユーザーで投稿 → そのダミーユーザーを削除して投稿も一緒に削除されるかどうかを確認してみたいと思います。
「php artisan migrate:fresh」を行うと、一度全てのテーブルが削除され、それからマイグレーションファイルを元にテーブルが作成されるとのことですが、それについて書かれてあるどのページを見ても疑問に思うことがあります????
結局のところ、今までに作ったマイグレーションファイルをもう一度マイグレートし直すのであれば、全てのテーブルを削除したところで同じこと、意味がないのではないかと思うのですが、どういうことなのかなぁと・・・(´・ω・｀)
そうですね、これまでの軌跡ということですから、途中で消して順を追って遡れなくなると、わけがわからなくなりますもんね????
マイグレーション操作についてはまだまだ学習の余地があると思っています^^;
よかったです!!
例えばですが、php artisan migrateをしたあとで、該当するmigrationファイルを削除すると、rollbackを行うことができなくなります。そこで、一旦「php artisan migrate:fresh」を行い、存在しているファイルのみで、テーブルを作成するというような感じではないでしょうか。(migrate:refreshだと、実質rollbackを行っているので、migrateしたはずのファイルが削除されているとエラーが発生するはずです。)
migrate:freshはKeightさんの言い方を加えると、これまでの軌跡が辿れないようなわけがわからない状態になった時の最終手段の初期化くらいに考えてもよいと思います。(本版環境で使うことはほとんどないといえます。よっぽど既存のテーブル構造が酷くない限り、しないと思います。酷くても既存データを写す作業を考えるとやりたくありませんね。)
以上は私の一意見なので、他にも理由はあると思います。
ありがとうございます。
お返事をいただける前に、一か八かで、詳しい挙動がわからないまま「php artisan migrate:fresh」を試してみました。
すると、これまでに削除したマイグレーションファイルは無視し、現存のマイグレーションファイルの内容までを表現してくれ、希望した状態から無事にやり直すことができることに気付くことができました！
また、外部キー制約の処理を施し、当該ユーザーのアカウントを削除すると、そのユーザーの投稿も同時に削除になるように実装もできました。
具体的には、「onDelete('cascade');」を付けるとうまくいきました！
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
いろいろとアドバイスいただき、ありがとうございましたm(_ _)m
あなたの回答
tips
プレビュー
