804

Laravelでテーブルを作るときにハマったとことか

あれこれハマって疲れたのでメモ。妥協の連続。

Migrate系

テーブルを作るときはartisan migrateで

ORMから弄るときにエラーが出たりするので artisan migrate で作るのが無難。

この前提があればmigrations配下の定義を弄るだけでdrop createが楽にできるという意味でもいいんじゃないかな…。

バイナリ系のERファイル管理するのも疲れるしね。

テーブルのPKはLaravelの標準に合わせる

$table->bigIncrements('id'); としておくとBigInt型のAutoIncrementなPKを作ってくれるので、余計なことは考えずこれに任せておきます。複合PKや、意味を持ったPKを切ろうとすると標準から外れた面倒な実装が必要になるので諦めました。

その変わりユニークにしたい要素に対しては $table->unique(['foo', 'bar']); としてUNIQUE制約を張っておくとINDEXにもなるのでいいんじゃないかと思います。PKはROWIDだと思って諦めました。

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘users’ already exists

$table->bigIncrements('id')->primary(); とかすると起きます。 bigIncrements() でPKになるのに primary() を書いてるので重複ということ。

ORM系

where id is null

Modelの primary をOverrideしておらず、テーブルに id という名前のPK列が存在しないときに updateOrCreate() を呼ぶと出てくるようです。

大人しくmigrationsの定義に $table->bigIncrements('id'); を付けておき、複合PKにしなければ出てきません。

恐らく updateOrCreate()は第一引数の条件で id を引っ張ってきて、その値で処理を行おうとしている気がします。

別に単一PKならModelの primary をOverrideすることでも解決しそうですが、面倒事が増えるだけなのでLaravelではテーブルのPKは $table->bigIncrements('id'); という管理にするのが最も無難に思えます。

個人的にはフレームワークを使う以上、なるべくお作法には従いところではあるので、ここも妥協。

なんか更新できない

Modelの protected $fillable= ['foo', 'bar']; に更新対象の列を書くと更新できるようになる。

りこ🍥
  • りこ🍥
  • 🌌ネトゲ廃人を経てWeb漂流物に成り果てた何か。さて次へ向かう先はどこやら。えっちらほっちら。

コメントする

メールアドレスが公開されることはありません。