JP
Status это enum разве у него может быть большой расход?
Size: a a a
2021 April 26
JP
По сути все просто. У меня просто психологическая травма после последного внедрения lockprovider
A
У меня была травма после работы с json без схем
JP
Были значит тикетс которые создавались принтером которые имеют проблемы с интернетом, потом операции с этими билетами идут по дальнейшему анонимному сценарию. Пошли дубли, появился редис. Понял что не помогло пришел на помощь lockprovider. Но, все равно это ошибка дизайна
JP
Весь прикол в том что каждый отдельный пользователь это новый поток
JP
При отсуствии потоков в пхп, по сути их наличие, особо не с кем было думать на тему а реально было бы сделать все правильно без lockprovider
JP
В принципе оно и так работает, это просто теоритическая часть такая
JP
там доли микросекунд мешают
A
Это уже проблема может через сессии провернуть
JP
не, они все равны)
JP
у них одна сущность)
JP
ковыряют скажем одну и ту же задачу
A
Uuid индификатор или что
A
Что даст уникальность
JP
Да но мне нужен номер следующего билета, его можно получить только узнав предвидущий
A
Просто задачка трешовая что то
JP
Но что делать если два клиента уже выбрали для себя номер билета
JP
и вместе херанули update set
JP
вот прикольно да
A
Составной первичный ключ