и в целом UoW это делать реализации репозитория

да, и при отсутствии persistance - тоже не нужна

да, и при отсутствии persistance - тоже не нужна

о чем ты?

о том, что не понимаю, почему ты частный случай persistance берешь за модель

.....

ясно, бесполезно

ну да, бесполезно, потому что этот посыл у тебя - аксиома

какой смысл ты вкладываешь в слова "частный случай persistance берешь за модель".

модель чего?

модель persistance?

потому что это требуемая для меня модель работы persistance

модель работы системы хранения

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

модель работы системы хранения

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

для этого я выбираю модель которая не имеет в принципе "системы хранения"

логично ж, нет?

или проблема в слове "модель"?

почему ты берешь "однопоточное неконкуретное nmemory хранилище" как модель работы системы хранения

uow не имеет отношения к системам хранения, она имеет отношения к бизнес-транзакции

почему в "идеальной системе" ты отказываешься от uow

почему ты берешь "однопоточное неконкуретное nmemory хранилище" как модель работы системы хранения

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

почему в "идеальной системе" ты отказываешься от uow

потому что UoW это средство которое позволяет добиться "почти идеальной системы"

ну то есть сначала идея о том что тебе надо что-то что скроет синхронизацию, а UoW как реализация этой идеи

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

или ты думаешь сначала придумали UoW а потом "зачем"?

по поводу "однопоточного" - ну как бы оно так и работает. Вспомни как ты работаешь с инкрементами в базе

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

если у тебя UoW умеет отслеживать операции инкремента

то есть с точки зрения клиентского кода у тебя все будет выглядеть так как если бы все просто в памяти лежало. А flush - ну его можно заменить например на @transactional аннотацию на уровне контроллера

я думаю, что когда придумывали uow, не держали в голове "сделать как будто у нас однопоточное" ;) а решали конкрентные проблемы построив реальную модель работы с субд

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

я думаю, что когда придумывали uow, не держали в голове "сделать как будто у нас однопоточное" ;) а решали конкрентные проблемы построив реальную модель работы с субд

я для тебя добавил "однопоточное" что бы ты не думал о локах

а ты думаешь о локах

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

в чем они разные, извини?

ну вот я тебе пример привожу

вот у тебя есть сущность с балансом и ты добавляешь 5

типа +5 для Пети твоего и -5 для Васи

как ты решаешь вопрос синхронизации?

писсиместичные локи в базе?

или как?

разные, ибо inmemory - не persistance

забудь о СУБД

или выбери один вариант

мускуль или постгрес там

и забудь о UoW

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

что ты будешь делать?

лочить ряды в базе, так

?

ага

в случае с immemory и многопоточностью ты точно так же будешь "лочить мьютексами/семафорами" проперти сущностей

так?

ага

в этой ситуации у нас для immemory флаша не появляется так как это разруливается на уровне сущностей

а вот если мы захотим "вычистить" сущности от инфраструктурного булшита с синхронизацией стэйта

как это не появляется, я буду в этом случае uow использовать ;)

как это не появляется, я буду в этом случае uow использовать ;)

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

а почему я должен сделать иначе?

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

а почему я должен сделать иначе?

ну потому что можно сделать иначе)

в целом ладно, убедил

только потому что inmemory быстрое

если с таким раскладом то да, везде будет UoW

но immemory repository поскольку прмиеняются только для тестирования - необходимости усложнять реализацию вводя UoW там нет

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

и для immemory и для обычных репозиториев

только потому что inmemory быстрое

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

ERROR: S client not available

UoW и flush это элементы инфраструктуры

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

вот там да - там упор на скорость

мне кажется сравнивать хранение стейта в памяти и persist стейта в общем не совсем верно

мне кажется сравнивать хранение стейта в памяти и persist стейта в общем не совсем верно

идея как раз таки в том что бы максимально скрыть эту разницу

оно конечно на 100% не выйдет

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

ну на самом деле it depends. Если у тебя два тест кейса например будут изолированы - то контракты не будут различаться)

ну мол UoW это как раз таки то средство которое позволяет твоему репозиторию действовать как inmemory

короч ладно, надо заканчивать

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

inmemory полезны только для демонстрации идеи которая приводит нас к UoW

Ребят, доброго времени суток всем.

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

Может есть у кого-нибудь набросок кода?

А-то в язык запросов могу совсем не очень :(

Вопрос не вполне ясен Кол-во объектов в массиве считается простым count($value)

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

массив или коллекция?

ибо "поле сущности" может быть и тем и тем если так подумать.

а мы тут не телепаты

но и в том и в том случае - простой count

только первое для массивов, а второе метод коллекции

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

Ребят, можно ли в Process в symfony передавать парные комманды? т.е. $process = new Process('cd /var/www/***/ && php bin/console ***');

вроде того

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

Ребят, можно ли в Process в symfony передавать парные комманды? т.е. $process = new Process('cd /var/www/***/ && php bin/console ***');

why not

спасибо :)

why not

Привет всем. Подскажите, есть ли в symfony шаблоны стартовые? Что-то типо basic, advanced в yii2? Спасибо.

шаблоны приложения?

Да.