[ad_1]
私は、多数のユーザーがそれぞれ独自の情報を持っているシステムに取り組んでいるため、それぞれのモデルを作成する必要がありました。 一方、これらすべてのユーザーは共通のユーザー モデルを持っており、その要件から資格情報が収集されるため、すべてのユーザー タイプとユーザー モデルの間に多態性の関係を持つことが適切でした。つまり、モデルとしてのコーディネーターとモデルとしてのユーザーです。次のことをしました
class Coordinator extends Model { protected $fillable= ['userid', ...]; ... public function user() { return $this->morphOne(User::class, 'userable'); } }
class User extends Model { ... public function userable() { return $this->morphTo(); } }
class CreateUsersTable extends Migration { public function up() { $table->bigIncrements('id'); ... $table->morphs('userable'); } }
class CreateCoordinatorsTable extends Migration { public function up() { $table->bigIncrements('coordid'); ... $table->foreign('userid')->references('ID')->on('wp_users')->onDelete('cascade'); } }
移行後、userable_type 列と userable_id 列で null が許可されていないことに気付きました。 コーディネーター エンティティとそれに関連付けられたユーザー エンティティを作成するにはどうすればよいですか?
私が試したこと:
ここで、列の null 可能性を変更して null を許可し、ユーザー モデルを保存してからその ID を取得し、コーディネーターを保存するときにそれを使用します。
解決策 1
検索したら出てきました Laravel 1 対多のポリモーフィックな関係 – レコードの作成。
そのアイデアは私が最初に考えていたものとは異なります。 を使用したとき、
$table->morphs('userable');
ユーザーテーブルには userable_id と userable_type の 2 つの列があり、それぞれデフォルトと ORM 規約により null が許可されておらず、ユーザーテーブルがマスターであり、他のテーブル(つまり、コーディネーター、教育者、配送者など)がそれぞれ考慮されていると考えていました。詳細テーブルとして。 この最初の間違った理解によれば、各テーブルに userid 列を追加して、特定のユーザータイプごとに関連するユーザー ID を保存していましたが、userable_id と userable_type を入力する必要があるユーザーを保存する方法を疑問に思っていました。特定のユーザーが最初にユーザーの userable_id に提供される ID を取得する場合、各テーブルにデータを保存できるようにするには、各テーブルにデータを保存した後にわかる情報が必要であるため、デッドロック状況に似ています。 !!。
しかし、上記のリンクの記事を読んだとき、私の考えとは逆にテーブルを考慮していることがわかりました(つまり、コーディネーター、荷送人などがマスターで、ユーザーテーブルが詳細である)。 これはモデルを直接使用する人にとってはそうですが、リポジトリ パッケージを使用する人にとっては少し難しく、追加の作業を行う必要があります…
[ad_2]
コメント