но в общем не суть... ;)

наркоманы...

секу

как насчет переопределить RepositoryManager

что бы тот по тегу доставал нужный сервис из контейнера?

и решить проблему на корню

вот это и была идея первая, да... удивился, что это решение не лежит где-то явно ;)

но потом забил и сделал через агрегацию, как и говорили в начале

ну это не проблема доктрины - это проблема этого fos elasticsearch bundle

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

я не инджекчу репы доктрины никуда

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

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

Сергей, а ты оставляешь конфигурацию repositoryClass для Entity ?

что значит "оставляешь"?

я ее не юзаю

не юзаешь, вот

то есть доктрина не узнает, как достать репозиторий для сущности

ей и не нужно

сторонние бандлы могут требовать $em->getRepository(class),

Ну он, видимо, пишет так, что бы никто никогда и не спрашивал доктрину "дай репу"... и в принципе я тоже думал пойти этим путем

чем плохо, если сохранять такую совместимость?

сторонние бандлы могут требовать $em->getRepository(class),

1. ну и пусть себе требуют. получат стандартный инстанс 2. я не использую таких бандлов и считаю это раком

Ну он, видимо, пишет так, что бы никто никогда и не спрашивал доктрину "дай репу"... и в принципе я тоже думал пойти этим путем

именно так, все исключительно через DI

а вто такой вопрос, юзаем мы реализацию репозитория InMemory и доктриновский, делаем их напоминающих коллекцию, и вроде как ожидаем, что после того как положишь в репо, в ней можно найти эту сущность (можно назвать это контрактом?). Так вот с InMemory всё хорошо, а вот с Doctrine обязательно нужно флашить.

нужно ли флашить сразу? или как-то запоминать сущности, которые ещё sheduledForInsertion, чтобы отдать их например в методе get($id)

` $book = new Book($isbn); $books->add($book); $books->get($isbn); // здесь должна быть сущность?

BookRepository::add(Book $book) { $this->em->persist($book); }

> (можно назвать это контрактом?) да, вполне

контракт регламентирует как твой объект будет себя вести в той или иной ситуации

> Так вот с InMemory всё хорошо, а вот с Doctrine обязательно нужно флашить. не обязательно, если ID уже есть и сущность была положена в unit of work

ну тут такой нюанс - если ты юзаешь findBy какой-нибудь - то да, это не прокатит.

а если по ID - то влегкую все будет работать

если смотреть по твоему примеру - то все будет работать корректно

если конечно ты не пользуешься богомерзскими автоинкрементами. Тогда ты просто напоролся на ограничение твоего слоя хранения данных и инфраструктуры. Увы и ах не все может быть идеальным.

либо тогда юзай uuid либо меняй базу на ту что умеет секвенсы

но вообще у меня к тебе другой вопрос - зачем тебе in memory репозитории?)

и определись какая из твоих реализаций нарушает контракт)

что было первым и кто является эталоном

но вообще у меня к тебе другой вопрос - зачем тебе in memory репозитории?)

не юзаю)

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

просто считаю, что должно быть так, как в InMemory

это в идеале должно быть, в этом смысл persistance ignorance, что бы оно работало все как in memory repository

ну делай flush каждый раз и будет так

это идеальная модель так скажем выполнения, которая увы не может быть реализована на 100% в реальности без огромных ограничений. Unif-of-work + identyty map как раз те штуки которые для твоего простого примера позволяют добиться одинакового поведения репозитория для работы с базой, и ин мемори

ну делай flush каждый раз и будет так

не, там замута с идеологической точки зрения

с идеологической тоже flush ;)

с идеологической тоже flush ;)

это не является ответом на вопрос, это что-то типа "а и хер с ним не буду разбираться почему так надо"

оно все всеравно к этому сведется

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

почему? это ответ. внутреннее состояние нужно синхронизировать со внешним... это, скорее, inmemory - исключение

почему? это ответ. внутреннее состояние нужно синхронизировать со внешним... это, скорее, inmemory - исключение

идея в том что не должно быть исключений

илаче у тебя не соблюдены контракты, нарушен LSP

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

и теряется всякий смысл в in memory repository. а если в нем нет смысла - можно уже задаваться вопросом зачем тебе вообще понадобилось что-то такое сложное как доктрина

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

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

короче, что бы проще - это вопрос о дихотомии persistance ignorance и ограничений инфраструктуры

ну тут такой нюанс - если ты юзаешь findBy какой-нибудь - то да, это не прокатит.

да, было именно такое. тогда и задумался, как разрешить проблему

нет никакой ложки, flush скрыт в репозитории

нет никакой ложки, flush скрыт в репозитории

нет, так делать некорректно

нет, так делать некорректно

а вот объясни

с чего бы?

да, было именно такое. тогда и задумался, как разрешить проблему

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

с чего бы?

для начала уточню - ты делаешь flush прямо в репозитории?

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

это не коллекция, там был поиск по уникальной паре

для начала уточню - ты делаешь flush прямо в репозитории?

угу, на методе add репозитория

это не коллекция, там был поиск по уникальной паре

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

это не коллекция, там был поиск по уникальной паре

findByCode($externalId, $project);

ERROR: S client not available

угу, на методе add репозитория

тогда ты не понимаешь зачем нужен flush, о чем дискуссия выше и есть

flush, как ты верно сказал, это "синхронизация состояния"

вот только выполняться эта синхранизация должна в конце бизнес транзакции

репозиторий не может и не должен знать где пролегает граница бизнес транзакции

репозиторий не может и не должен знать где пролегает граница бизнес транзакции

вот не очень понятно, почему?

хотя я не делаю флаши в репозитории

вот не очень понятно, почему?

репозиторий = полки. Она хранит книги. Полка не очень то и знает что происходит с книгами, кто их берет, зачем, что с ними делает и т.д

ее работа - хранить книги

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

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

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

или еще пример

ты положил книгу на полку, и есть у тебя еще учетные записи читателей

т.е. ты хочешь сказать, что в случае эталонной inmemory репы вопросов бизнес-транзакций не возникает? ;)

т.е. ты хочешь сказать, что в случае эталонной inmemory репы вопросов бизнес-транзакций не возникает? ;)

там такая же схема. Это тупое хранилище

более реальный пример ибо мне лень выдумывать

раз такая же схема, как ты закончишь бизнес транзакцию в случае inmemory репозитория?

1. достаем заказ из репозитория по айдишке 2. просим его поменять статус 3. при изменении статуса заказ внутри себя запоминает когда и с какого статуса на какой были изменения. Типа лога. Записывает это в коллекцию свою минуя репозитории ибо в этом случае заказ это и есть корень агрегата а коллекция связей выступает как im-memory репозиторий.

раз такая же схема, как ты закончишь бизнес транзакцию в случае inmemory репозитория?

immemory репозиторий тоже не знает, об этом знают вещи на уровень выше

идеальный вариант делать flush - контроллер

т.е. для inmemory репозитория тоже нужен flush?

т.е. для inmemory репозитория тоже нужен flush?

нет, для inmemory репозитория не нужна синхронизация

flush нужен для того что бы ты работал с данными в базе так, как если бы они были в inmemory репозитории. Эдакий кастыль для того что бы более четко разделить ответственность

(если что под контроллером я тут подразумеваю сферический GRASP контроллер)

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

не понимаю ;) если flush по твоему - завершение бизнес транзакции, а для inmemory - ее нет, то у нас inmemory может находится в неконсистентном состоянии

не понимаю ;) если flush по твоему - завершение бизнес транзакции, а для inmemory - ее нет, то у нас inmemory может находится в неконсистентном состоянии

расскажи как мне что такое неконсистентное состояние

и как консистентный объект который лежет в памяти может потерять консистентность?

p.s. представь себе однопоточное PHP приложение которое хранит вообще все данные в памяти и никогда не падает и вот для этой ситуации

объектов может быть много

со связанными состояниями

и? это не задача репозитория - это задача твоих сущностей как не выходить из консистентного состояния