Мне кажется у нас разное понимание литералов))

Литерал это $foo = 'bar'; вот bar это литерал. Это определение литерала. Буквально строка в коде.

Есть модуль комментов. У него 4 контракта для других модулей: create(type, parentId, text) remove(id) update(id, newtext) getList(type, parentId)

Ну и как ты хочешь "плохо" запихать куда то литерал?

При рефакторе такое как правило проебывается. Поэтому суют в константы

Зачем он там вообще? ) это проблема внешних сервисов, идентифицировать у себя там чтото

В сервисе комментов не нужно. Достаточно просто по иду пачку записей запросить

Зависит от частоты, да

На самом деле коллизии с типом тоже будут возможны, с ууидом)

На самом деле коллизии с типом тоже будут возможны, с ууидом)

Вот со счётчиком проблема да. Но решаема лишним запросом в сервис с последующим кешированием. В остальном хз. Ну м.б. ещё показать 1-2 последних коммента

Может мое тож нормально. Сходу накинулся )

Да ты сам уже несколько проблем подтвердил )) но ты все равно ишешь варианты как это использовать и решать проблемы, когда можно просто их не создавать изначально)))

Ну хз, твой вариант на сохранение это дискриминатор на запись. Он в атрибутах вообще. Но все равно создаёт каплинг. Потому что зависимости явно прописываются. Потом, тип нужен по большому счету для того, чтобы аатоинкремет не пересекался в полиморфных таблицах. С ууидом этой проблемы быть не должно. Как-то так

Хз, я сам не уверен можно ли считать за каплинг зависмость в атрибутах... 😄

Что за зависимость в аттрибутах?

Явно прописанные связи в дискриминаторе

Выше уже говорил, просто стринг поддерживать тяжко будет. Надо будет поменять тип и чо делать? Миграцию писать?

Есть модуль комментов. У него 4 контракта для других модулей: create(type, parentId, text) remove(id) update(id, newtext) getList(type, parentId)

Ну вот мне надо будет поменять значение в поле type, как?

Хз, приспичит

Назвал тип неудачно. Или появилась похожая сущность или ещё какая дичь.

Это тоже самое, что поменять названия констант, енамов, а потом думать что делать с БД

Про это и речн

дискриминатор - это объектная штука - позволяет твои энтити наследовать.. А тебе тут наследование не нужно. Достаточно просто поле с типом и id родителя хранить

Обычно все по другому ) и заранее не думают. Вот как ты сейчас, говоришь что это бред ) назвал бы article и все. Потом позже появился бы ещё один такой тип, и ты захочешь поменять. Тип articlefoo, articlebar

Так похер же, это ключ связи который нигде не фигурирует по факту кроме запросов. Хоть "выаываыва23323kljkjkj" назови, только не меняй Ты когда нить обращался к внешнему сервису с вопросом: "мне не нравится ключ доступа который вы выдали, сделайте красивый" ?)

Тут я сам задаю ключ, и это другое 😄

Будет все "по фен-шую", вдруг я в прод базу полезу, и должен буду понимать чё там

Может да, но будет человекочитаемым с вероятностью 99.99% )

Всем привет! Нормально вообще так делать? interface CommentableInterface { ... } class Album implements CommentableInterface { ... } class Photo implements CommentableInterface { ... } interface CommentInterface { ... public function setParent(?CommentableInterface $parent): static; ... } abstract class Comment implements CommentInterface { ... } class AlbumComment extends Comment { ... public function setParent(?CommentableInterface $parent): static { if (!is_a($parent, Album:class)) throw new Exception(); ... } ... } class PhotoComment implements Comment { ... public function setParent(?CommentableInterface $parent): static { if (!is_a($parent, Photo:class)) throw new Exception(); ... } ... }

Почему не наследовать какой-то абстрактный класс родительский для всех комментариев? Доктрина же так умеет

С комментариями в целом все сложнее чем кажется на первый взгляд. Все очень зависит от задачи. Если просто отсортировать по счётчику комментов это одно, если надо наиболее цитируемое за последние сутки, то вообще другая реализация будет. Для последних комментов на сайте отдельный пиздец. В обзоре показать под постом последние 3 коммента тоже будет не просто.