AK
¯\_(ツ)_/¯
Size: a a a
2020 March 11
A
Ну главное что при прыжках туда-обратно скидка не теряется.
VT
Ну главное что при прыжках туда-обратно скидка не теряется.
а вот если бы она еще и на APP перешла, ух
A
а вот если бы она еще и на APP перешла, ух
Она и переходит.
А
да, если другие продукты не нужны, то даунгрейд делаешь и по факту получаешь просто +3 месяца для PS
а хаки с конверированием APP в PHPStorm не сработают? :)
VT
Она и переходит.
да? конкретно в этом случае, или это вообще так работает?
я думал лояльность копится только по конкретному продукту
я думал лояльность копится только по конкретному продукту
A
а вот если бы она еще и на APP перешла, ух
У меня показывает цену за месяц 14.9, при оригинальной цене в 24.9
A
да? конкретно в этом случае, или это вообще так работает?
я думал лояльность копится только по конкретному продукту
я думал лояльность копится только по конкретному продукту
Я тоже так думал. Оказывается лояльность копится по пользователю.
А
да? конкретно в этом случае, или это вообще так работает?
я думал лояльность копится только по конкретному продукту
я думал лояльность копится только по конкретному продукту
В прошлом году при продлении phpStorm мне вылезало предложение перейти на APP с текущей скидкой
Так что бывает и такое
Так что бывает и такое
VT
В прошлом году при продлении phpStorm мне вылезало предложение перейти на APP с текущей скидкой
Так что бывает и такое
Так что бывает и такое
ну я такое предложение тоже видел пару месяцев назад, но я думал что это типа акция
BT
словно халяву взяли
квест пройди и получишь халяву
A
получилось сконвертить в год лицензии phpStorm, круто
Хм? Оно посчитало, сколько эти 3 месяца APP стоит и пересчитало эту сумму по цене пхпшторма?
AK
получилось сконвертить в год лицензии phpStorm, круто
четко, спасибо за лайфхак
RH
пацаны, ситуация, нужен совет.
и так, есть доктрина, на энтите User вистит postUpdate событие которое анализирует поле status и в завимости от результа шлет в рэбит пакет с user->id
в консюмере по айдишнику берется юзер и в зависимости от статуса и других признаков чет делается.
проблема: иногда, в конюсмере, em->find(user->id) возращает сущность с неактуальным статусом. похоже на то, что пакет в рэбит прилетает раньше чем postUpdate завершает работу, по этому и данные не свежие.
—
пробовал в консюмере делать em->refresh() – иногда помогает, но в целом шляпа же
пробовал в postUpdate перед паблишингом в очередь делать flush на этой сущности, тоже не ок
—
можно извратится и в консюмер передавать не айди юзера а все необходимые поля, но хочется сначала разрулить проблему архитекурно.
и так, есть доктрина, на энтите User вистит postUpdate событие которое анализирует поле status и в завимости от результа шлет в рэбит пакет с user->id
в консюмере по айдишнику берется юзер и в зависимости от статуса и других признаков чет делается.
проблема: иногда, в конюсмере, em->find(user->id) возращает сущность с неактуальным статусом. похоже на то, что пакет в рэбит прилетает раньше чем postUpdate завершает работу, по этому и данные не свежие.
—
пробовал в консюмере делать em->refresh() – иногда помогает, но в целом шляпа же
пробовал в postUpdate перед паблишингом в очередь делать flush на этой сущности, тоже не ок
—
можно извратится и в консюмер передавать не айди юзера а все необходимые поля, но хочется сначала разрулить проблему архитекурно.
ЕР
пацаны, ситуация, нужен совет.
и так, есть доктрина, на энтите User вистит postUpdate событие которое анализирует поле status и в завимости от результа шлет в рэбит пакет с user->id
в консюмере по айдишнику берется юзер и в зависимости от статуса и других признаков чет делается.
проблема: иногда, в конюсмере, em->find(user->id) возращает сущность с неактуальным статусом. похоже на то, что пакет в рэбит прилетает раньше чем postUpdate завершает работу, по этому и данные не свежие.
—
пробовал в консюмере делать em->refresh() – иногда помогает, но в целом шляпа же
пробовал в postUpdate перед паблишингом в очередь делать flush на этой сущности, тоже не ок
—
можно извратится и в консюмер передавать не айди юзера а все необходимые поля, но хочется сначала разрулить проблему архитекурно.
и так, есть доктрина, на энтите User вистит postUpdate событие которое анализирует поле status и в завимости от результа шлет в рэбит пакет с user->id
в консюмере по айдишнику берется юзер и в зависимости от статуса и других признаков чет делается.
проблема: иногда, в конюсмере, em->find(user->id) возращает сущность с неактуальным статусом. похоже на то, что пакет в рэбит прилетает раньше чем postUpdate завершает работу, по этому и данные не свежие.
—
пробовал в консюмере делать em->refresh() – иногда помогает, но в целом шляпа же
пробовал в postUpdate перед паблишингом в очередь делать flush на этой сущности, тоже не ок
—
можно извратится и в консюмер передавать не айди юзера а все необходимые поля, но хочется сначала разрулить проблему архитекурно.
Что не ок с флашем перед публикацией сообщения?
RH
Что не ок с флашем перед публикацией сообщения?
не афектит никак, в консюмере все равно не свежая запись