может так

если я правильно понял

Это по поводу моего вопроса?)

Yes !

к нам дамы добавляются

вот таких банить нужно

эгегей, админы

+1

Ребята, вопрос по рейс кондишенам и архитектуре согласованности в очередях

1)Админом обновляется юзер - регистрируется задача #update-1 в очрееди на обновление юзера в 1С 2)Эта задача #update-1 начинает выполняться - происходит ошибка из-за таймаута коннекта к 1С - она кладется в очередь отложенных обработок 3)Админу похеру: пока там задача пытается выполнится - он еще раз обновляет юзера, добавляя еще какие-то правки - создается задача #update-2 на обновление юзера в 1С 4)Вот теперь 2 задачи не могут выполниться какое-то время и прыгают по очереди из отложенной очереди в основную через определенный интервал 5)К этому времени, неожиданно начинает работать 1С и к этому времени пытается выполниться задача #update-2 - она выполняется успешно и только после начинает выполняться #update-1, который затирает изменения #update-2 - последние изменения, которые хотел сделать админ

У меня реббит, если это важно

1)Админом обновляется юзер - регистрируется задача #update-1 в очрееди на обновление юзера в 1С 2)Эта задача #update-1 начинает выполняться - происходит ошибка из-за таймаута коннекта к 1С - она кладется в очередь отложенных обработок 3)Админу похеру: пока там задача пытается выполнится - он еще раз обновляет юзера, добавляя еще какие-то правки - создается задача #update-2 на обновление юзера в 1С 4)Вот теперь 2 задачи не могут выполниться какое-то время и прыгают по очереди из отложенной очереди в основную через определенный интервал 5)К этому времени, неожиданно начинает работать 1С и к этому времени пытается выполниться задача #update-2 - она выполняется успешно и только после начинает выполняться #update-1, который затирает изменения #update-2 - последние изменения, которые хотел сделать админ

так очередь можно и по времени формировать

Можешь кейс описать?

Можешь кейс описать?

https://habrahabr.ru/post/235983/ https://github.com/rabbitmq/rabbitmq-delayed-message-exchange твое с первой задачей всегда выйдет с очереди первым

Да с плагином проблема ставить его

Слишком дофига* бумаг надо

У меня разруливается через x-message-ttl и x-dead-letter-exchange

Возможно буду делать через https://symfony.com/doc/current/components/filesystem/lock_handler.html

На каждую каку создавать

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

Да с плагином проблема ставить его

не понял какая проблема? в каталог положил со всеми плагинами и выполнил в ребите rabbitmq-plugins enable rabbitmq_delayed_message_exchange https://bintray.com/rabbitmq/community-plugins/rabbitmq_delayed_message_exchange/v3.6.x#files

Ребята. Такой вопрос. Есть entity User. Должна возможность создать Admin, Moderator, User. Есть допустим сервис User у которого есть методы для создания таких сущностей (т.к. разный набор полей для каждого нужен). Так вот вопрос, передавать параметрами createAdmin($email, $password, ...) или создавать заранее в контроллере entity, сетить туда параметры необходимые и передавать в нужный метод? Как правильнее? Красиво аолучается с передачей ентити, но не очень нравится, что надо модель создавать в контроллере.

вообще ничего не понял

)

Сейчас постараюсь понятнее

Или даже проще. Можно ли создавать ентити в контроллере? Для того чтобы готовый объект передать в сервис для дальнейших действий

$user = new Entity\User(); $user->setName('Vasya'); $user->setEmail('vasya@gmail.com'); $userService->createAdmin($user);

Можно ли так делать в контроллере?

Или надо: $userService->createAdmin('name', 'email');

этот код в контроллере

с моделькой покрасивше

Да, но пугает немного создание в контроллере ентити (

и с порядком полей не ошибёшься

А что в этом такого? В базу из контроллера ты не лезешь и даже доктрину не дёргаешь

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

Хотелось как можно больше разгрузить контроллер

А почему вы вообще в контроллере не имеете объект? Я про форму, она отдаёт же объект. Т.е. в контоллере надо получить объект, тем или иным способом. Валидатор лучше вынести, чем тоньше класс , тем лучше, как по мне. Принцип единственной ответственности и все такое.

в контроллере должен быть объект иначе как записывать

а валидацию можно отдельно вынести

$form->isValid

Ребят, скажите пожалуйста, почему в профиль всех пускает?

А почему вы вообще в контроллере не имеете объект? Я про форму, она отдаёт же объект. Т.е. в контоллере надо получить объект, тем или иным способом. Валидатор лучше вынести, чем тоньше класс , тем лучше, как по мне. Принцип единственной ответственности и все такое.

Валидатор в смысле в контроллере $form->isValid сделать? У меня не получалось нормально уникальность валидировать модели. ValidatorInterface с этим справлялся

Нене, валидатор в общем смысле я имел ввиду

С телефона много не напишешь

Не совем понял про валидатор

Все что связано с валидатор интерфейс в отдельный класс, я про это говорил

Хм, ну у меня перед каждоый записью в базу вызывается: $errors = $this->validator->validate($entity);

это в сервисе

так норм? я к тому что это не в контроллере, а в сервисе

Я бы поднял вызов в контроллер

А в сервис пихнул бы валидную модель

Получается валидация формы и валидация энтити

Ну грубо говоря да. Вообще, я не делал сложные валидации с формами, но по хорошему бы через аннотация сделать валидацию

и форму исключить..

У меня так сейчас и работает

и форму исключить..

Эм. Не уверен, что это хорошая идея. Но тут вам виднее, я не знаю ваш кэйс

рест апи

т.е. по сути форма и не нужна (если валидация в модели)

рест апи

Аа, да, для апи я делал отдельные валидаторы

У меня там форм нет

Сейчас смотрю на graphql

Понятно ) Спасибо!

Есть еще одно но, что если сервис вызывается из другого места, не из контроллера

т.е. к примеру не передали пароль, а в сервисе это не проверяется

Есть еще одно но, что если сервис вызывается из другого места, не из контроллера

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

Я про случай, к примеру придётся потом вызвать сервис из консольной команды. Сервис же он на то и сервис что должен быть независимой сущностью.

Я про случай, к примеру придётся потом вызвать сервис из консольной команды. Сервис же он на то и сервис что должен быть независимой сущностью.

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

Если использовать способ передачи в сервис готовой модели, получается что нет уверенности, например, что пароль не пустой.

Если использовать способ передачи в сервис готовой модели, получается что нет уверенности, например, что пароль не пустой.

вы наверно не так поняли, что я писал выше, или я написал сумбурно :) Чтобы быть уверенным, что модель валидна, у вас несколько путей решения этой задачи. Первый и достаточно очевидый - использовать валидатор внутри сервиса - инжектим/содаем инстанс и выполняем валидацию. Если не валидно, бросаем исключение/возвращаем ответ с состоянием. Другой вариант, мы подразумеваем, что наша модель идет в сервис уже валидной, что означает, что вызов валидатора должен быть на уровень (или несколько выше), в том же контроллере или команде, но он должен быть обязательно. Да, я согласен, что by design, он более подвержен коллизиям, когда, к примеру, кто-то сделал вызов и передал параметром не прошедший валидацию аргумент. Но, все это регулируется соглашениями дизайна системы. Почему я порекомендовал вынести валидатор выше на уровень, из сервиса - чтобы убрать выброс исключительной ситуации, к примеру, чтобы уменьшить количество затраченных шагов до проверки состояния объекта, чтобы упростить логику сервиса и т.п. Только ради этого.

Понял, да, именно для безопасности и делаю в сервисе валидацию. Возможно ещё зависит от ситуации. Спасибо)

Такой вопрос!

Допустим есть поля в бд firstname lastname, можно ли их в один input затолкнуть ? Может, кто сталкивался

по пробелу делил как-то

т.е. получается допустим делаю один input с Ф.И. , на выходе он мне пишет в два поля first и last

типо того, но это если не очень важны эти данные, потому что все равно буду писать и ФИ и ИФ и ИИФ

будут* писать

блин, если даже 2 инпута сделать, могут писать коряво

от этого не застрахован ни кто

стоит ли вообще это делать ?

объеденять в один? Большая форма?