Здравствуйте, хорошее видел) Но сколько материала посмотрел и почитал, ни кто не рассказывает как выводить одновременно через один контроллер все комментарии к моделям артиклей и блогов)
Когда я впервые освоил полиморфные отношения, я добавил комментарии ко всему, чему можно, добавил комментарии к комментариям, к коментариям добавились лайки, лайки на комментарии, лайки на лайки, лайки на комментарии к лайкам😂
И ещё один момент, который стоило упомянуть - почему некоторые разработчики не жалуют morph связи. Чтобы сохранить гибкость и оставить за собой возможность переименовать связанную модель и не потерять эту самую связь: в поле *_type можно записывать не название класса модели, а свое значение, указанное 3 параметром в методах motphTo...
Минусов у данной реализации тоже много, имхо. В рамках одной таблицы многократно увеличивается количество записей, невозможно настроить внешние ключи, в случае бага в модели, слетают все комментарии во всех сущностях.
А на домашку задание: "Сделать миграцию для переноса данных из обычной таблицы comments в poly_comments. Миграция должна откатываться (частичная потеря данных допустима" 😂 Вот теперь миграцию можно по праву считать миграцией)
Благодарю за видео. Не понимаю смысл полиморфа, это же смешение разных контекстов (bounded contexts). "Комментарий к статье" и "комментарий к фото" могут иметь разный размер, разные ограничения и правила валидации, разный набор полей, участвуют в разных поведениях и событиях. Также будет сложно потом сделать модульную (компонентную) структуру.
Так если разные контексты, то и полиморфность не подходит. Полиморфность больше для случаев, типа "вот этот комментарий, что я сейчас пишу вам" ) Он может быть к видео, к посту, к другому комментарию, но имеет одинаковый размер, ограничения и вплидацию
Не подскажете как реализовать сохранение комментария для статьи, причем на вьюхе статьи будет тексареа, которая будет стучаться в контроллер комментария, и надо каким-то образом связать коментарий с статьей. В будущем другие сущности также будут иметь коментарии.
Дали проект, где все на этих полиморфных отношениях. Это просто жесть, все тормозит, индексов нет, целостность базы нарушить очень легко,так как нет внешних ключей, из-за этого везде софтделиты, из-за которых база будет надуваться со временем. Это если какую-то мелкую вещь делать сойдет, но не все на полиморфных отношениях
Представьте, что вы модератор и модерируете комментарии в ВК, которые могут быть к посту, к фото, к видео и т.п. У вас в админке все комментарии отовсюду. Что проще сделать запрос комментов из одной таблицы или из разных таблиц (комменты к фото, комменты к видео и т.п)
@@ОлегВячеславович-т1о наверное точно любителем. Не понятно как может добавление одного where (по фиксированному набору типов) в запросы может существенно повлиять на скорость
Ценю Ваши видео и труд, но хватит учить людей пихать id-шники отношений в fillable и напрямую писать туда. Для этого есть замечательные методы associate, sync и т.д.
![KAYTRANADA - Witchy (feat. Childish Gambino) [Official Video]](http://i.ytimg.com/vi/jGK3YVmGZ3Y/mqdefault.jpg)
Волнуюсь за отношения в Laravel больше, чем за свои.
Добро пожаловать в клуб)
Как раз не знал как правильно сделать такую структуру!
😊
Когда-то изучал комментарии в вордпресе и не понимал, что за структура такая интересная) Спасибо, очень полезно!
✨
Спасибо вам от Белгии - все работает отлично в моем проекте
Круть!! Так держать! Очень клевые видосы, даже книжку прикупил поддержать ) за одно мб чего полезного и нового узнаю )
Спасибо за поддержку!
ждём ещё новых видео😊 как всегда намного интереснее смотреть ваши уроки чем у других
😎
Здравствуйте, хорошее видел) Но сколько материала посмотрел и почитал, ни кто не рассказывает как выводить одновременно через один контроллер все комментарии к моделям артиклей и блогов)
Пипец ты шаришь конечно 10/10 просто
🙏
Когда я впервые освоил полиморфные отношения, я добавил комментарии ко всему, чему можно, добавил комментарии к комментариям, к коментариям добавились лайки, лайки на комментарии, лайки на лайки, лайки на комментарии к лайкам😂
Такой звук хороший. Я аж наушники снял, думал через колонку звук пошел
Работаем и над качеством звука, спасибо
И ещё один момент, который стоило упомянуть - почему некоторые разработчики не жалуют morph связи.
Чтобы сохранить гибкость и оставить за собой возможность переименовать связанную модель и не потерять эту самую связь: в поле *_type можно записывать не название класса модели, а свое значение, указанное 3 параметром в методах motphTo...
Минусов у данной реализации тоже много, имхо.
В рамках одной таблицы многократно увеличивается количество записей, невозможно настроить внешние ключи, в случае бага в модели, слетают все комментарии во всех сущностях.
А на домашку задание: "Сделать миграцию для переноса данных из обычной таблицы comments в poly_comments. Миграция должна откатываться (частичная потеря данных допустима" 😂
Вот теперь миграцию можно по праву считать миграцией)
Благодарю за видео. Не понимаю смысл полиморфа, это же смешение разных контекстов (bounded contexts). "Комментарий к статье" и "комментарий к фото" могут иметь разный размер, разные ограничения и правила валидации, разный набор полей, участвуют в разных поведениях и событиях. Также будет сложно потом сделать модульную (компонентную) структуру.
Так если разные контексты, то и полиморфность не подходит.
Полиморфность больше для случаев, типа "вот этот комментарий, что я сейчас пишу вам" ) Он может быть к видео, к посту, к другому комментарию, но имеет одинаковый размер, ограничения и вплидацию
Не подскажете как реализовать сохранение комментария для статьи, причем на вьюхе статьи будет тексареа, которая будет стучаться в контроллер комментария, и надо каким-то образом связать коментарий с статьей. В будущем другие сущности также будут иметь коментарии.
Можно ли по такому принципу делать многоязычную систему?
Дали проект, где все на этих полиморфных отношениях. Это просто жесть, все тормозит, индексов нет, целостность базы нарушить очень легко,так как нет внешних ключей, из-за этого везде софтделиты, из-за которых база будет надуваться со временем. Это если какую-то мелкую вещь делать сойдет, но не все на полиморфных отношениях
Упустили Морфмапы и m2m для полиморфных. Или это в следующем видео?
MorphToMany были а мапов не будет
@@CutCodeRu может не так написал. Не MorphToMany, а ManyToMany (Polymorphic), там где pivot таблица ещё
@@TsA1ex morphtomany метод называется laravel.com/docs/10.x/eloquent-relationships#many-to-many-polymorphic-relations
Это не будет работать на нескольких миллионов записей . На больших проектах лучше разделять.
Почему не будет? Это тот же самый запрос, только +1 where условие. И модель с таблицей будет по полю type определяться
Представьте, что вы модератор и модерируете комментарии в ВК, которые могут быть к посту, к фото, к видео и т.п. У вас в админке все комментарии отовсюду. Что проще сделать запрос комментов из одной таблицы или из разных таблиц (комменты к фото, комменты к видео и т.п)
@@TsA1ex Будет очень тормозить, у меня проект написан прошлым любителем полиморфных отношений, тормоза просто ужасны.
@@ОлегВячеславович-т1о наверное точно любителем. Не понятно как может добавление одного where (по фиксированному набору типов) в запросы может существенно повлиять на скорость
Ценю Ваши видео и труд, но хватит учить людей пихать id-шники отношений в fillable и напрямую писать туда. Для этого есть замечательные методы associate, sync и т.д.