качестве базы sqlite и проблемы такой не было, а проблема в следующем:
Представим кейс (для примера), есть инлайн кнопочка, при нажатии получаем 50 игровых монеток раз в 30 минут (или 5 сек, как на видео)
Callback-handler там такой:
> селектится значение таймера из бд (timestamp)
> если пришло время забирать монетки, апдейтим во первых сам таймер (добавляем 30 минут к нему), а во вторых накидываем монеток
А в чём проблема? На поверхности всё ок, но если мы отключим интернет на телефоне, быстро покликаем на кнопочку, врубим обратно сеть, то увидим что кнопочка заюзалась не один раз, а 5 (зависит от того как быстро кликал)
Что посоветуете, как зафиксить? Поставил сейчас тротлет, чтоб хоть как-то приглушить проблему, но есть способы обхода и игроки быстро догадаются. И это затычка, нежели решение.
Сохраняй в бд таймстемп последнего пополнения, а не ближайшего будущего
Мне тогда 25к строчек когда придётся переписать, у меня всё в таком стиле сделано. Да и дело не в этом скорее всего, результат будет аналогичным.
Заранее продумывать нужно) и нет, это вполне исправит ситуацию Повторное нажатие не отработается
Заранее не надо было продумывать, так как всё безупречно работало с прошлой бд, на протяжении 9 месяцев. Ща попробую твой вариант и отпишусь
вроде когда начал читать увидел что то в тебе хорошее и тут f в запросах
кто юзает ф-строки в бд запросах тот лох чмо гитлер
тот фашист и педераст
врятли гитлер лохом был
чмом уж тем более
ну если и был то ему мог об этом только сталин сказать)
так я и за гитлера ничего не говорю
так ты гитлером и лохом и чмом назвал
Так Сталин ему и сказал, а иначе из-за чего начался весь сыр-бор и война?
ну так я ж не гитлера назвал
Потому что работа с скулайт идет в один поток, наверное
Причина - запросы конкурентно обрабатываться не могут, и обрабатываются один за другим. А в посгресе могут, и гонка. Причина всегда код, но это ответ на «почему в скулайт работало»
Обсуждают сегодня