отдельной таблице.
Абсолютно точно отдельная таблица, потому что это позволило мне одновременно и решить проблему с правами. Может, кому-то такое очевидно, но я очень сильно пропёрся ) Реализация такая:
Есть модель User. Есть Course. И есть модели StudentOfCourse, AuthorOfCourse, EditorOfCourse.
Каждая такая модель - это обычная pivot-таблица с user_id и course_id, например. Но в ней есть и свои поля, специфичные для этой роли.
В User прописаны отношения типа:
$user->studentsOfCourses(), $user->authorsOfCourses() и т.д.
Поверх каждого отношения описана обвязка $user->studentOfCourse(1), $user->authorOfCourse(1), которая возвращает экземпляр ну или null.
Собственно, крутость в том, что проверка прав и т.д. происходит просто за счёт наличия отношения:
public function update(Course $course) {
if($user->authorOfCourse($course->id)) {
$user->authorOfCourse($course->id)->doUpdate()
Еще большая прелесть в том, что т.к. эти пивоты обычные модели, у них могут быть и свои релейшены. Например
$user->teacherOfCourse(1)->students()
Как-то так ) Круто же? Или есть какие-то минусы такой реализции?
Это называется STI. В доктрине и cycle реализовано из коробки.
Почитал ) Да, концепция та же самая, но реализация не совсем. Насколько я понял, главная фишка sti - что нет joinов при запросе
https://gist.github.com/roxblnfk/0376dc7f1eec34262994fda3d4cdef36#file-jti-sti-ru-md
Это обычное морф отношение, не?
Обычные отношения, но не морф )
Попробуй как тут ) @ttsergey
Обсуждают сегодня