Size: a a a

2021 March 18

ПГ

Павел Г. in symfony
Anton K.
еще один кейс есть. когда нам надо удалить объект из бд, но перед этим мы обязаны сделать http запрос на апи. во. если мы не достучались до апи, то можно и не удалять
Если перед этим, то это вообще или синхронно, или как раз таки проверка апи должна кидать ивент на удаление объекта
источник

ПГ

Павел Г. in symfony
Да и причем тут вообще событие.
источник

AK

Anton K. in symfony
то есть синхронно вызовом кода перед $em->delete($entity)? и так везде, где может быть удален объект? если он вдруг в нескольких местах удалиться может
источник

AK

Anton K. in symfony
я кину событие, что объект планирует удаляться и листенеры это все обработают как надо
источник

ПГ

Павел Г. in symfony
Anton K.
то есть синхронно вызовом кода перед $em->delete($entity)? и так везде, где может быть удален объект? если он вдруг в нескольких местах удалиться может
У вас что, много разных хэндлеров на удаление? Оберните в обертку это поддержка DRY а не события
источник

S)

Shokha )) in symfony
#[IsGranted(['ROLE_TABLE_WRITE'])]
такое аннотации еще не работает да контроллере
источник

AK

Anton K. in symfony
Павел Г.
У вас что, много разных хэндлеров на удаление? Оберните в обертку это поддержка DRY а не события
$em->delete($entity) мой хендлер и мне больше ничего не потребуется. это прозрачно и реюзабельно
источник

ПГ

Павел Г. in symfony
Anton K.
$em->delete($entity) мой хендлер и мне больше ничего не потребуется. это прозрачно и реюзабельно
Короче че мы спорим. Вам нравится так и вас устраивает - делайте. А нас так :) Наверное пора закончить)
источник

ПГ

Павел Г. in symfony
Может кто подскажет верный ли путь, и какой верный если нет :) Задачка думаю для многих банальная.
Кейс:
1) получение сущности
2) Проверка что данные по апи были получены ранее
2) Запрос по апи
3) Добавление данных из апи
4) Установка флага что данные по апи получены
5) Сохранение  

При даблклике проиходит двойное сохранение (не знаю можно ли это назвать рейскондишеном) не смотря на проверку в начале п2. Ну в приниципе логично.

Как такое верно разруливать? Я обернул в транзакцию и установил пессимистик write (хотя и с read работает) лок на пункт 1. Вроде работает. Но мб есть более грамотное решение?
источник

A

Arky in symfony
Павел Г.
Может кто подскажет верный ли путь, и какой верный если нет :) Задачка думаю для многих банальная.
Кейс:
1) получение сущности
2) Проверка что данные по апи были получены ранее
2) Запрос по апи
3) Добавление данных из апи
4) Установка флага что данные по апи получены
5) Сохранение  

При даблклике проиходит двойное сохранение (не знаю можно ли это назвать рейскондишеном) не смотря на проверку в начале п2. Ну в приниципе логично.

Как такое верно разруливать? Я обернул в транзакцию и установил пессимистик write (хотя и с read работает) лок на пункт 1. Вроде работает. Но мб есть более грамотное решение?
заблочить кнопку?)0
источник

ПГ

Павел Г. in symfony
Arky
заблочить кнопку?)0
Это понятно, что надо и на фронте решать :)
источник

A

Arky in symfony
Павел Г.
Это понятно, что надо и на фронте решать :)
селект фор апдейт еще есть
источник

ПГ

Павел Г. in symfony
Arky
селект фор апдейт еще есть
это наверное и есть пессимистик
источник

ПГ

Павел Г. in symfony
И еще вопрос: кто как это реализовывает на уровне репо? Допустим есть метод get(int $id).  Без лока.  Создавать еще один метод getWithLock? Или это не имеет никакого смысла и во всех методах get делать с локом? Но сам по себе лок будет срабатывать только внутри транзакции.
источник

AK

Anton K. in symfony
Павел Г.
Может кто подскажет верный ли путь, и какой верный если нет :) Задачка думаю для многих банальная.
Кейс:
1) получение сущности
2) Проверка что данные по апи были получены ранее
2) Запрос по апи
3) Добавление данных из апи
4) Установка флага что данные по апи получены
5) Сохранение  

При даблклике проиходит двойное сохранение (не знаю можно ли это назвать рейскондишеном) не смотря на проверку в начале п2. Ну в приниципе логично.

Как такое верно разруливать? Я обернул в транзакцию и установил пессимистик write (хотя и с read работает) лок на пункт 1. Вроде работает. Но мб есть более грамотное решение?
1) из бд?
2) ранее чего? запроса из бд?
3) запрос какой? на обновление? или чтение сущности через апи? то есть получаем данные из бд, потом по апи её обогощаем?
источник

ПГ

Павел Г. in symfony
Anton K.
1) из бд?
2) ранее чего? запроса из бд?
3) запрос какой? на обновление? или чтение сущности через апи? то есть получаем данные из бд, потом по апи её обогощаем?
Да,  сущность из бд. Запрос по api - http
источник

ПГ

Павел Г. in symfony
Забрали из БД сущность, обогатили данными из http запроса, обновили сущность
источник

Z

Zavisxo in symfony
Hello everyone
источник

Z

Zavisxo in symfony
Im need help , i hope someone help me
источник

Z

Zavisxo in symfony
For symfony
источник