$user->getCommentsCount() в принципе

то это кака и должно выноситься в отдельный Dao

А где хранить это DAO? <sarcasm>Можно конечнов контроллер</sarcasm>, но может есть более правильное решение?

А где хранить это DAO? <sarcasm>Можно конечнов контроллер</sarcasm>, но может есть более правильное решение?

можно в контроллере, но лучше не в контроллере.

вообще в рамках симфони не обязательно так загоняться и можно все в репосах хранить

либо выносить в Query functions

$user->getCommentsCount() в принципе

это всё конечно ок, но что если мне не нужны объекты? ну вот в том же случае репортов

кастомный реп?

это всё конечно ок, но что если мне не нужны объекты? ну вот в том же случае репортов

выше 2 сообщения

мы о кастомных репах и говорим

можно все в репосах хранить, если там два-три метода. Если они разрастаются, то нужно загоняться иначе будет беда, рефакторить тяжело. phpstorm уже умеет резолвить правильно $em->getRepository(Foo::class)->findByCustomQuery ? Раньше была беда, помогали репы как сервисы

>$em->getRepository(Foo::class) не делай так плз

а magic finders это вообще ппц

>$em->getRepository(Foo::class) не делай так плз

Почему?

Почему?

потому что это сервис локатор

потому что это сервис локатор

И?

сервис-локатор зло :)

А как тогда обратиться к репо?

Ведь даже в оф доках так делают

иньекция через конструктор

регистрируешь репос как сервис и потом инжектишь через конструктор в сервисы и контроллеры

иньекция через конструктор

Хмм.. Буду знать, Спасибо. Но все же хотелось бы поподробнее узнать в чем может быть зло? Я всего год работаю с симфони, и пока каких-то проблем не было

Хмм.. Буду знать, Спасибо. Но все же хотелось бы поподробнее узнать в чем может быть зло? Я всего год работаю с симфони, и пока каких-то проблем не было

- почти везде entity manager есть, где он нужен и не нужен, даже если нужно всего 1 репос достать. а em предоставляет еще работу с транзакциями и персистом, оно тебе точно везде нужно? - в одном сервисе может доставаться 10 разных репосов и ты в принципе не заметишь что давным давно нарушил SRP и твой сервис раздулся до невменяемых размеров - ты используешь сервис локатор, который признан злом еще десяток лет назад. об этом много чтива есть - чтобы писать юнит тесты тебе нужны двойные стабы, стаб на ЕМ и стаб на репос, что не очень то и удобно и выразительно - автовайринг симфони не можешь юзать

https://www.tomasvotruba.cz/blog/2017/10/16/how-to-use-repository-with-doctrine-as-service-in-symfony/ это?

примерно да

можно manager registry пушить вообще, чтобы не было проблем с entity manager is closed

но у нас немного проще AppBundle\Repository\Users: factory: ["@doctrine.orm.entity_manager", getRepository] arguments: [AppBundle\Entity\User]

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

А такой момент. Репозиторий может прятать в себе flush, например?

А то вроде как репозиторий может уметь читать не только с базы данных с использованием доктрины, но и со стороннего api например, а писать в сторонний апи как?

да

Надо же как-то прятать flush и доктрину

нет

Ну еб

:(

хотяяяя

Ну спорная херня

по сути у тебя должен быть интервейс UserRepoInterface

И реализации

для доктрины

для хуйпоймичо

А там внутри реализация

Я такдумаю

Надо же как-то прятать flush и доктрину

если ты пишешь в сторонний апи, зачем тебе доктрина?) это уже реализация самой апи должна заниматься

если у тебя атомарная транзакция, то без проблем можешь делать и remove и save, во всех c#/java интерфейсах репозиториев такое есть вот только репос должен работать только со своей сущностью, поэтому в доктрине такого по-умолчанию в репосах нет, ибо генериков еще не подвезли) но если нужны сложные транзакции или когда обновлять нужно несколько обьектов, тогда уже без прямого использования em никак

Надо же как-то прятать flush и доктрину

Ну, я флашу в контроллере после выполнения всех работ. Инжектю $em в контроллер.

> когда обновлять нужно несколько обьектов, тогда уже без прямого использования em никак У меня ощущение что это говно

Потому что у меня так и есть

Ну, я флашу в контроллере после выполнения всех работ. Инжектю $em в контроллер.

чем раньше закрыл транзакцию, тем лучше. вот например ты отправил уже эмейл юзеру, а транзакция еще не закрыта, и в контроллере оказывается что она не может быть закрыта и нужен откат

чем раньше закрыл транзакцию, тем лучше. вот например ты отправил уже эмейл юзеру, а транзакция еще не закрыта, и в контроллере оказывается что она не может быть закрыта и нужен откат

Тогда будет получаться своего рода AR, если сразу сейвить все. Но я думаю что вы правы. В варианте с имейлом, можно подвязать ивент на постФлаш

у меня в репо-методе есть такая штука типа $parrent->isNew() тогда $parrent->addChild($child) иначе $child->save()

Тогда будет получаться своего рода AR, если сразу сейвить все. Но я думаю что вы правы. В варианте с имейлом, можно подвязать ивент на постФлаш

ивенты доктрины не должны участвовать в логике приложения в принципе

ивенты доктрины не должны участвовать в логике приложения в принципе

Что ты вкладываешь в понятие "ивенты доктрины"

Что ты вкладываешь в понятие "ивенты доктрины"

preFlsuh, postFlush и так далее

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#lifecycle-events

окей

тогда как сделать сохранение файла(аватарки)?

Нужно удостоверится что транзакция прошла

и только тогда сделать $file->move()

Это делать в контроллере?

Или в репо?

Или в ивенте?

в сервисе

Можно генерить событие

и его обрабатывать

Ну вот я так и сделал

ERROR: S client not available

Типа PostCreateEvent

обычно событие не доктировские хуки )

аплоад это 2 разных операции, ты сразу получаешь темповый файлик, потом перемещаешь его куда-либо, и только потом сохраняешь в базе линку на этот файл

обычно событие не доктировские хуки )

и в самом событии делать флаш?)

нет

обычно событие не доктировские хуки )

Допустим в случае обновления сущности, где персист я не делаю)

аплоад это 2 разных операции, ты сразу получаешь темповый файлик, потом перемещаешь его куда-либо, и только потом сохраняешь в базе линку на этот файл

Я сначала генерю имя файла. Потом все это сохраняю в базу. Если транзакция прошла -> тригерю ивент в который кладу эту сущность и в нем сохраняю файл

Допустим в случае обновления сущности, где персист я не делаю)

Флаш точно не в ивенте.

Ивент после флаша

а если кончилось место на диске, диск недоступен, проблема с сетью и другие катаклизмы, которые не дают сохранить файл, а у тебя уже сохранена линка на это имя?

а если кончилось место на диске, диск недоступен, проблема с сетью и другие катаклизмы, которые не дают сохранить файл, а у тебя уже сохранена линка на это имя?

хм

Да. Будет плохо

А чо тогда делать?

у нас терабайты картинок, и есть куча всяких чекеров которые проверяют консистентность базы и файловой системы. но мы изначально сохраняем файл куда-либо, а потом уже в базе создаем и меняем записи

иначе могут быть ситуации когда линка ведет на несуществующую картинку, или битую картинку

окей

а если транзакция не прошла?

плюс есть еще ресайзы, которые тоже должны быть готовы

Удалять файл?

файлы вычищаются отдельными скриптами, которые следят за консистентностью

Ну ресайзы у вас же не на лету

в том то и дело, что в базу транзакция пойдет далеко не сразу

Как вариант -> создавать в очередь таску на сохранение файла.

картинка предварительно проходит 4-5 этапа обработки

и последний этап это сохранение в базу его

картинка предварительно проходит 4-5 этапа обработки

Как то не очень

Тобишь POST метод может тупить?

Ждать пока картинка сохранится

и если IO забито то все?

у нас немного другой кейс

Ну ок