Это уже вопрос к тому, как ты приложение деплоишь

Понял. Спасибо большое

Можете мне подсказать как делать in memory like репозитории, если есть такие проблемы, как:
1. Транзакции и implicit commit. Клиент ожидает, что всё пройдёт в одну транзакцию, хотя под капотом уже прошёл коммит.
2. Непонятно как использовать manager->persist с batchSize + manager->flush для множественных вставок/обновлений в методах репозиториев
3. Как работать с объектами, если для множественной вставки использовали dbal, а не orm
4. Как совместить commit от транзакции БД и flush/commit от ORM UoW в одной абстракции и корректно ли это вообще делать

И как работать с ORM в принципе, если она на batch insert/update предлагает отказаться от manager->persist и использовать dbal?

Ну т.е. понятно, что можно по разному сделать (Ocramius/DoctrineBatchUtils) и так даже делают, но это же по сути откровенный костыль в текущем подходе. И вообще не понятно как с репозиториями их скрестить...

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

Вариантов есть несколько:
1) привязывать отображение логов к verbosity и использовать (к примеру) -q
2) да, перенаправлять в /dev/null
3) настроить уровни логирования с env переменными и выставлять некий LOG_LEVEL=critical при ручном запуске команд

Какую проблему решаем? Что логи именно мешают работе (нельзя перенаправить вывод в другую команду/файл), или неудобство смешивания перед тем, кто запускает?

Через SocialConnect получаю юзера. прежде чем сохранить его в db, хочу запросить его в отдельной форме.  ясно что можно Access/Userinfo token положить в сессию и перенапоавить на страницу, где и запросить пароль.
Хотел спросить вас, м. б. есть что-то более элегантное?

> нужно ин-мемори хранилище, которое поддерживает транзакции

Можно и не ин-мемори брать. Ведь репозитории — это лишь абстракция.

> dbal более низкоуровневая штука, которая о самой ORM ничего не знает

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

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

Абстракции это хорошо, но в концепции коллекции объектов нет понятия транзакций. Вы же хотите его иметь, а значит ваши абстракции текут и начинают зависеть от конкретных деталей реализации. И так, чтоб в абстрактном РЕПО были транзакции вам нужно хранилище с поддержкой транзакций.

По поводу дбал, это также самая история. Есть объектная абстракция, но она не бесплатна в плане производительности. И если вы упёрлись в производительность, то шлете абстракцию в пень и обращаетесь к более конкретному дбал. Это уже костыль само по себе. Ваш вопрос выглядит довольно комично в этом разрезе

> но в концепции коллекции объектов нет понятия транзакций

Почему это нет? С объектами тоже можно проводить неатомарные операции, а значит всё те же проблемы. К примеру, при работе в многопоточной среде это вообще изи.

> Вы же хотите его иметь

Не проблема их сделать в принципе, проблема скорее как работать с БД, когда они её закрывают раньше времени при ряде операций, которые являются деталью реализации репозиториев, а не частью интерфейса.

> абстракции текут и начинают зависеть от конкретных деталей реализации

Нет. Транзакции делаем отдельно от репозиториев. Проблема лишь в том, что из-за операции в репозитории внешняя транзакция закрывается.

> И если вы упёрлись в производительность, то шлете абстракцию в пень

Проблема производительности исключительно из-за того, что сама Доктрина не умеет в bulk inserts и предлагает использовать костыли, в том числе и dbal, хотя это нифига не решение. Да, я это прекрасно знаю, я ищу варианты решения, а не информацию, что это является костылём.

> Ваш вопрос выглядит довольно комично в этом разрезе

Я предполагаю, что вы не поняли сути моего вопроса, учитывая вышеизложенное.

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

Ну так-то орм сама по себе тот еще костыль и компромисс.

Как работать с орм при батч инсерт/апдейтах, если важна производительность? Никак.

Можно выносить тяжелые операции в отдельные процессы(консольные команды, бас консумеры и т.п.), юзать там дбал, и не пытаться натянуть сову на глобус, умножая сложность.

Коллеги, кто ищет работу. Требуется middle php. Основной фрейм Symfony 5. От 800р/ч от 30ч в неделю.

Подробности в личку.

Всем доброго дня, а кто-нибудь использует бандл LexikJWTAuthentication ? Я правильно понимаю, что он не заработает с новым аутентификатором  https://symfony.com/doc/current/security/experimental_authenticators.html ?

Привет, ни у кого такого не было в шторме с терминалом? макось, zsh

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

может есть способ проще ?

Graceful shutdown. Если у тебя нет проблем при одновременной работе сразу нескольких контейнеров/сервисов, то остается только успешно один из них завершать. Замена одного на другой будет без проблем.

в это и вопрос, docker при остановке контейнера завершает процессы внутри gracefull или убивает напрочь ?

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

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

Он посылает сигнал о завершении с ожиданием успешного завершения. А дальше зависит от таймаута ожидания и самого процесса, который этот сигнал примет или проигнорирует