Можете мне подсказать как делать 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

> нужно ин-мемори хранилище, которое поддерживает транзакции Можно и не ин-мемори брать. Ведь репозитории — это лишь абстракция. > dbal более низкоуровневая штука, которая о самой ORM ничего не знает Я это прекрасно знаю. Дело в том, что советуют использовать более низкоуровневую абстракцию игнорируя высокоуровневую, из-за чего в дальнейшем нет адекватной возможности работать с высокоуровневой (т.к ранее мы обошли вариант с хранением объектом в ней, из-за чего uow ничего о объектах и не знает). И, собственно, стоит вопрос — какие абстракции с каким интерфейсом должен быть, что бы код не был костылём и представлял из себя что-то удобное.

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

> но в концепции коллекции объектов нет понятия транзакций Почему это нет? С объектами тоже можно проводить неатомарные операции, а значит всё те же проблемы. К примеру, при работе в многопоточной среде это вообще изи. > Вы же хотите его иметь Не проблема их сделать в принципе, проблема скорее как работать с БД, когда они её закрывают раньше времени при ряде операций, которые являются деталью реализации репозиториев, а не частью интерфейса. > абстракции текут и начинают зависеть от конкретных деталей реализации Нет. Транзакции делаем отдельно от репозиториев. Проблема лишь в том, что из-за операции в репозитории внешняя транзакция закрывается. > И если вы упёрлись в производительность, то шлете абстракцию в пень Проблема производительности исключительно из-за того, что сама Доктрина не умеет в bulk inserts и предлагает использовать костыли, в том числе и dbal, хотя это нифига не решение. Да, я это прекрасно знаю, я ищу варианты решения, а не информацию, что это является костылём. > Ваш вопрос выглядит довольно комично в этом разрезе Я предполагаю, что вы не поняли сути моего вопроса, учитывая вышеизложенное.

Ну так-то орм сама по себе тот еще костыль и компромисс. Как работать с орм при батч инсерт/апдейтах, если важна производительность? Никак. Можно выносить тяжелые операции в отдельные процессы(консольные команды, бас консумеры и т.п.), юзать там дбал, и не пытаться натянуть сову на глобус, умножая сложность.