Заметка С бюлдинные го exe файлы находят в папке AppData\Local\Temp

Oo почему не в папке проекта? Ты как сборку запускаешь? go build?

Парни, массив в пайтоне может принимать идеально ~1 млн символов?

Идеально?

Идеально?

Да

Да

Зачем? Так то и больше можно

Я вообще вопрос не понял

Гайс вопросик. Есть бот в тг на асинхроне для обмена криптой, вся инфа о балансах хранится в бд, как быть уверенным в том что пока проводится сделка между двумя пользователями, один из этих пользователей не вывел деньги? То есть как быть увереным что после проверки if user.balance == trade.amount баланс пользователя не изменится, все же делается асинхронно ?

Гайс вопросик. Есть бот в тг на асинхроне для обмена криптой, вся инфа о балансах хранится в бд, как быть уверенным в том что пока проводится сделка между двумя пользователями, один из этих пользователей не вывел деньги? То есть как быть увереным что после проверки if user.balance == trade.amount баланс пользователя не изменится, все же делается асинхронно ?

Попробуй сделать в бд constraint

Попробуй сделать в бд constraint

То есть?

Или select for update

Гайс вопросик. Есть бот в тг на асинхроне для обмена криптой, вся инфа о балансах хранится в бд, как быть уверенным в том что пока проводится сделка между двумя пользователями, один из этих пользователей не вывел деньги? То есть как быть увереным что после проверки if user.balance == trade.amount баланс пользователя не изменится, все же делается асинхронно ?

сonstraint в базе на поле balance > 0. И списание делать апдейтом update ... set balance = balance - amount

Или select for update

Так про constraint понял, а что за селект фор апдейт?

Или select for update

Или вот так вот с lock'ом, да

сonstraint в базе на поле balance > 0. И списание делать апдейтом update ... set balance = balance - amount

А можно пример полного запроса?

А можно пример полного запроса?

update user_balance set balance = balance - 100 where user_id = 42

update user_balance set balance = balance - 100 where user_id = 42

а constraint ?

а что за субд?

а constraint ?

А это в create table

а что за субд?

postgres

CREATE TABLE products ( product_no integer, name text, price numeric CONSTRAINT positive_price CHECK (price > 0) );

Лучше наверно select for update, мало ли какая там ещё логика

либо alter table {name table} add constraint {name constraint}...

А это в create table

Ааа, все понял, я думал это при апдейте

Лучше наверно select for update, мало ли какая там ещё логика

Пессимистичные локи это не всегда хорошо

https://github.com/Tishka17/sber_test вот похожий кейс

Лучше наверно select for update, мало ли какая там ещё логика

Да не, впринципе с отрицательным баланс никак не работаю, думаю можно обойтись constraints

https://github.com/Tishka17/sber_test вот похожий кейс

деанон

Я уже много на кого досье набрал

деанон

Ой да меня нагулить прям проблема

у тебя тут очепятка

Ой да пофиг

Там ещё и двухфазный комит не дописан

Да не, впринципе с отрицательным баланс никак не работаю, думаю можно обойтись constraints

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

с select for update можно и в коде

Понял, всем спасибо

int 13h

Понял, всем спасибо

То есть выход: constraints на неотрицательны баланс + проверка баланса в запросе? Select for update здесь нужен?

То есть выход: constraints на неотрицательны баланс + проверка баланса в запросе? Select for update здесь нужен?

Не проверка баланса в запросе, а вычисление нового баланса прямо в update-запросе. При такой схеме select for update не нужен

Кстати!

А как такие ограничения делать средствами СУБД?

Триггеры?

CREATE TABLE products ( product_no integer, name text, price numeric CONSTRAINT positive_price CHECK (price > 0) );

О_о

CREATE TABLE products ( product_no integer, name text, price numeric CONSTRAINT positive_price CHECK (price > 0) );

Почему это не делать в коде?

CREATE TABLE products ( product_no integer, name text, price numeric CONSTRAINT positive_price CHECK (price > 0) );

Если при запросе мы попробуем установить отрицательный баланс, нам выдаст ошибку, а что пользователю говорить? Типо попробуйте позже ?

Перенос части бизнес логики в хранилище - не самое лучшее решение

Почему это не делать в коде?

Предложите решение без пессиместичных блокировок

Предложите решение без пессиместичных блокировок

Ну ты делаешь чек прайса в бд. зачем - непонятно

Ну ты делаешь чек прайса в бд. зачем - непонятно

Затем чтобы нельзя было установить отрицательный прайс

Если при запросе мы попробуем установить отрицательный баланс, нам выдаст ошибку, а что пользователю говорить? Типо попробуйте позже ?

Да, будет ошибка. При ошибке можно снова проверить баланс пользователя и если он действительно недостаточный показать пользователю соответствующую ошибку. Но в любом случае, даже если забыть сделать обработку ошибки, то лучше пускай будет 500ка, чем баланс придет в неконсистентность

Затем чтобы нельзя было установить отрицательный прайс

повторю вопрос - почему это не делать в бизнес логике приложения?

повторю вопрос - почему это не делать в бизнес логике приложения?

Как?

У вас что, данные сразу в базу приходят?

нет

приведи пример (можно на псевдоязыке) как будет выглядеть списание с пользователя определенной суммы

На моем последнем проекте я ввел поле balance в сущность "кошелек"

На что мне сказали - "аяяй" так делать

Баланс должен высчитываться всегда из транзакций

И если нужно скорости - кешировать его

У вас что, данные сразу в базу приходят?

Я могу их обработать до попадания в бд, но где гарантия того что при асинхронных запросах пока делается проверка баланс не изменится ?

Баланс должен высчитываться всегда из транзакций

типа иначе неконсистентность данных будет

Я могу их обработать до попадания в бд, но где гарантия того что при асинхронных запросах пока делается проверка баланс не изменится ?

понял проблему. Юзайте SSI, раз у вас Postgres

типа иначе неконсистентность данных будет

Ну, парни выше написали что можно делать блокировку строк, но еще написали что это плохо

ERROR: S client not available

понял проблему. Юзайте SSI, раз у вас Postgres

при чем здесь SSI вообще?

Ну, парни выше написали что можно делать блокировку строк, но еще написали что это плохо

Ну это не то чтобы плохо. Но в определенных кейсах может быть неприемлемо

Да мне кажется норм тема с кешированием баланса

при чем здесь SSI вообще?

это лучше чем пессиместичные блокировки

и не хранить его в кошельке

Да мне кажется норм тема с кешированием баланса

ну считай, что поле balance в кошельке это и есть кэш

Да мне кажется норм тема с кешированием баланса

так и стоит делать в принципе

так и стоит делать в принципе

Как это решит проблему с возможным получением отрицательного баланса?

Ну это не то чтобы плохо. Но в определенных кейсах может быть неприемлемо

Плюс еще палки в колеса в виде взаимоблокировок

Как это решит проблему с возможным получением отрицательного баланса?

окей. как он может получиться в этом случае?

окей. как он может получиться в этом случае?

не, чувак, погоди. Ты набросил тему, что constraint'ы в базе это зло, и проверку надо делать в коде. Я тебя попросил привести пример как эта проверка будет выглядеть

давай сначала с этим разберемся

не, чувак, погоди. Ты набросил тему, что constraint'ы в базе это зло, и проверку надо делать в коде. Я тебя попросил привести пример как эта проверка будет выглядеть

я сначала неправильно понял проблему. Потом в замен тем же пессиместичным блокировкам предложил SSI. При SSI не возникнет ситуации с отрицательным кошельком.

что такое SSI?

что такое SSI?

Serializable Snapshot isolation

я сначала неправильно понял проблему. Потом в замен тем же пессиместичным блокировкам предложил SSI. При SSI не возникнет ситуации с отрицательным кошельком.

ну и констрейты тут не пригодятся, насколько я представляю

Serializable Snapshot isolation

оу, а я подумал что ты про тот самый древний SSI (https://en.wikipedia.org/wiki/Server_Side_Includes)

оу, а я подумал что ты про тот самый древний SSI (https://en.wikipedia.org/wiki/Server_Side_Includes)

ахах

оу, а я подумал что ты про тот самый древний SSI (https://en.wikipedia.org/wiki/Server_Side_Includes)

+1 :))

ахах

да, я аж чаем подавился ))

Serializable Snapshot isolation

Можешь вкратце описать что это и как работает?

Типа, не дает закоммитить транзакцию

Если до коммита был выполнен коммит в другой транзакции

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

Если до коммита был выполнен коммит в другой транзакции

затрагивающий те же данные

Да

да

Прикольная штука, ннада будет изучить ее глубже. Мне это пригодится

получается, в таких случаях выполнять подобного рода операции нужно в цикле?

типа в декоратор какой нить обернуть