Я очень проникся sublime merge лучше VS-ского и очень удобно смотреть что там как, "блеймить" и разбирать историю, сравнивать коммиты из разных веток. А комитить удобно из командной строки (это супер быстро) либо из GUI если нужно частями.
Я обращаю внимание на различия в типах самих транзакций — либо это рандомные транзакции или идет event stream. Плюс насколько часто меняются значения. В моей ЛИЧНОЙ практике необходимость читать много раз запись неизменной не попадалась. Изменения баланса я делаю обычно атомарной транзакцией: считал значение, записал изменение — за один вызов. Чтобы использовать более высокие уровни изоляции... даже не знаю — это скорее для подведения балансов может быть нужно, когда важно чтобы разные концы базы данных не менялись в течение процесса. Но я бы делал это просто на реплике, либо на снапшоте базы данных. Это надежнее и базу не грузит. Пишут, что полезно, когда нужно выбирать на какой счет из списка счетов блокировку средств ставить, для меня — теория. Лично не сталкивался.
Возможно у меня профессиональная деформация, так как я постоянно имею дело с фин. транзакциями, и имею большой опыт с ленивыми транзакциями и Django-ой, но проблема здесь для меня была очевидна сразу... Так как база — это собственно источник информации о состоянии — и он должен быть единственным, то идея правильная, но есть нюанс... В вашем способе факт блокировки записи и является промежуточным "состоянием" процесса платежа. Это нехорошо: блокировка у вас долгая, и все это время держит базу данных "привязанной" к конкретному процессу — в результате все равно ненадежно. Поэтому в платежах обычно делают два шага: создают (быстро-быстро) намерение, а потом либо его завершают платежом либо фейлят (т. е. неудачный платеж). Так база оказывается более эффективной. Ну а искать тогда можно не платеж, а намерение (его конечно тоже через select for update надо делать, но это микросекунды).
Очень не хватает конечно асинхронности, но похоже, что либо асинхронность, либо плюшки ОРМ. Я использую Торнадо, когда необходим бескомпромиссный асинк, но фреймворк всё таки нужен.
А вообще джаваскрипт + джанго очень удобное сочетание для большинства проектов.
меня смутил 1 воркер (я ставлю 3); и про сертификаты сейчас писать надо сразу, потому что без HTTPS далеко не уехать. И, конечно, лучше делать конфиг в /etc/nginx/sites-available, и следующим шагом делать ln -s линк в /etc/nginx/sites-enabled. Иначе, когда будете варианты делать, nginx будет с ума сходить от количества противоречивых записей и откажется запускаться.
Мне нравится Торнадо, быстро, очень быстро, и ровно то, что нужно для поддержки JS в темплейтах + асинхронность + алхемия. статик обслуживает nginx. Что ещё нужно для полета в космос?
все батарейки разбора реквестов в наличии.
минус - нет админки (с 10000 строк в м2м поле на выбор ..)
Я очень проникся sublime merge лучше VS-ского и очень удобно смотреть что там как, "блеймить" и разбирать историю, сравнивать коммиты из разных веток. А комитить удобно из командной строки (это супер быстро) либо из GUI если нужно частями.
Я обращаю внимание на различия в типах самих транзакций — либо это рандомные транзакции или идет event stream. Плюс насколько часто меняются значения.
В моей ЛИЧНОЙ практике необходимость читать много раз запись неизменной не попадалась. Изменения баланса я делаю обычно атомарной транзакцией: считал значение, записал изменение — за один вызов. Чтобы использовать более высокие уровни изоляции... даже не знаю — это скорее для подведения балансов может быть нужно, когда важно чтобы разные концы базы данных не менялись в течение процесса. Но я бы делал это просто на реплике, либо на снапшоте базы данных. Это надежнее и базу не грузит.
Пишут, что полезно, когда нужно выбирать на какой счет из списка счетов блокировку средств ставить, для меня — теория. Лично не сталкивался.
Возможно у меня профессиональная деформация, так как я постоянно имею дело с фин. транзакциями, и имею большой опыт с ленивыми транзакциями и Django-ой, но проблема здесь для меня была очевидна сразу...
Так как база — это собственно источник информации о состоянии — и он должен быть единственным, то идея правильная, но есть нюанс... В вашем способе факт блокировки записи и является промежуточным "состоянием" процесса платежа.
Это нехорошо: блокировка у вас долгая, и все это время держит базу данных "привязанной" к конкретному процессу — в результате все равно ненадежно. Поэтому в платежах обычно делают два шага: создают (быстро-быстро) намерение, а потом либо его завершают платежом либо фейлят (т. е. неудачный платеж). Так база оказывается более эффективной.
Ну а искать тогда можно не платеж, а намерение (его конечно тоже через select for update надо делать, но это микросекунды).
Очень не хватает конечно асинхронности, но похоже, что либо асинхронность, либо плюшки ОРМ. Я использую Торнадо, когда необходим бескомпромиссный асинк, но фреймворк всё таки нужен.
А вообще джаваскрипт + джанго очень удобное сочетание для большинства проектов.
меня смутил 1 воркер (я ставлю 3); и про сертификаты сейчас писать надо сразу, потому что без HTTPS далеко не уехать. И, конечно, лучше делать конфиг в /etc/nginx/sites-available, и следующим шагом делать ln -s линк в /etc/nginx/sites-enabled. Иначе, когда будете варианты делать, nginx будет с ума сходить от количества противоречивых записей и откажется запускаться.
Мне нравится Торнадо, быстро, очень быстро, и ровно то, что нужно для поддержки JS в темплейтах + асинхронность + алхемия. статик обслуживает nginx. Что ещё нужно для полета в космос?
все батарейки разбора реквестов в наличии.
минус - нет админки (с 10000 строк в м2м поле на выбор ..)