Как хранить полиморфные связанные модели

Question

Я работаю в системе, в которой много пользователей, каждый из которых имеет свою информацию, поэтому мне нужно было создать модель для каждого из них.С другой стороны, у всех этих пользователей есть общая пользовательская модель, в которой их учетные данные собираются из тех требований, что было бы целесообразно иметь полиморфную связь между всеми типами пользователей и пользовательской моделью, т. Е. Координатор как модель и пользователь как модель Iсделал следующее

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.Почему я создаю объект-координатор со связанным с ним объектом-пользователем?

Answer 1

Я получил это после поиска в Google ...

Laravel Один ко многим Полиморфные отношения - создание записей

Идея не такая, как я думал в начале.Когда я использовал $table->morphs('userable');, пользовательская таблица имела два столбца, userable_id и userable_type, и каждый из них не допускает нулевого значения по умолчанию и в соответствии с соглашением ORM, и я думал, что они считают, что пользовательская таблица является главной и другими таблицами (то есть, координатор,преподаватель, грузоотправитель и т. д.) каждый в качестве подробной таблицы.В соответствии с этим первоначальным неправильным пониманием я добавлял столбец идентификатора пользователя в каждую таблицу, чтобы сохранить связанный идентификатор пользователя для каждого конкретного типа пользователя, и мне было интересно, как я собираюсь сохранить пользователя, которому необходимо заполнить идентификаторы userable_id и userable_type, сохранивконкретный пользователь сначала получает свой идентификатор, который будет предоставлен для userable_id пользователя. Случай напоминает ситуацию взаимоблокировки, поскольку каждая таблица нуждается в части информации, которая будет известна после сохранения данных для каждой, чтобы иметь возможность сохранять данные в каждой таблице, проводной!!!.

Однако, когда я прочитал статью по приведенной выше ссылке, я понял, что она рассматривает таблицу противоположным образом, в отличие от моего мышления (т. Е. Координатор, грузоотправитель и т. Д. Являются хозяевами, а пользовательская таблица -деталь).Это для парней, которые используют модели напрямую, но для тех, кто использует пакет репозитория, это немного сложно, и вам нужно проделать дополнительную работу ...