Если я ничего не путаю, то внутри page_dispatcher можно создать динамически свой набор url pattern'ов по списку страниц пользователя, а дальше использовать https://docs.djangoproject.com/en/dev/ref/urlresol... Опять же созданный список url pattern'ов, вероятно, есть смысл как-то кешировать.
яндекс.маркет — последнее место, где стоит искать ноуты по параметру «время автономной работы». там тупо указаны данные, которые приводит производитель, а производители никогда не отличались честностью в этом вопросе. 15 минут хождения по гуглу показывают, что из шести указанных моделей только один ноут (самсунг qx412) действительно способен продержаться хоть сколько нибудь близко к 10часовой отметке, а именно около восьми с половиной часов в режиме серфинга по интернету. плюс к этому: хреновые корпуса (кроме разве что тошибы), большой вес (кроме дорогого фуджика) и цены, которые себя никак не оправдываютяндекс.маркет — последнее место, где стоит искать ноуты по параметру «время автономной работы». там тупо указаны данные, которые приводит производитель, а производители никогда не отличались честностью в этом вопросе. 15 минут хождения по гуглу показывают, что из шести указанных моделей только один ноут (самсунг qx412) действительно способен продержаться хоть сколько нибудь близко к 10часовой отметке, а именно около восьми с половиной часов в режиме серфинга по интернету. плюс к этому: хреновые корпуса (кроме разве что тошибы), большой вес (кроме дорогого фуджика) и цены, которые себя никак не оправдывают
поддержу. я пробовал эклипс, нетбинс, vim, emacs, gedit, kate, и еще кучу других редакторов, которые уже и не вспомню, но остановился на IntelliJ IDEA с плагином для питона. IDEA и PyCharm построены на одной и той же платформе, просто мне приходится работать не только с питоном, но иногда с руби, пхп и жабой, поэтому простой PyCharm мне не подошел
@DeNnEr понимаю, что вопрос очень старый, но не понял про threading и multiprocessing. GIL, конечно, работает в обоих случаях, но в случае с multiprocessing создаются не потоки, а процессы, значит, если я все правильно понимаю, будет по гилу на процесс, так что он не будет мешаться на CPU bound задачах. правильно?
Да, это правда, деньги не малые и их, конечно, жалко. С другой стороны закосить по здоровью выйдет в районе 100-120к, полагаю, так что разница не такая уж и большая, плюс вариант легальный. Кроме того, 50к в год — это цены в Москве, в ближайших регионах цены могут быть в два-три раза меньше (я серьезно, можете сами узнать расценки), а это уже другой разговор. :) Да, во всех этих рассуждениях я исхожу из предложения, что вам не хочется тратить время ни на аспирантуру, ни на армию. Впрочем, решать вам, конечно. :)
да, наверное именно потому, что люди в армии становятся заметно мудрее, мало кто захочет ехать в поезде полном дембелей, а день десантника считается самым безопасным днем для прогулок на свежем воздухе.
пересчитывать account на каждый чих — не вариант, это весьма ресурсоемкая операция, поэтому, видимо, все-таки эта сущность нужна
что касается точки обновления, она и так одна, есть у Account такой метод — update_balance. но как раз из вопроса должно быть понятно, что одновременно может существовать несколько питонячих объектов для одной записи БД. и вызов этого метода у разных объектов как раз и приведет к проблеме. а метод может вызываться в разных местах, это как раз нормально
про select for update — смотрите предыдущий ответ и мой комментарий к нему
вообще, наиболее грамотно принцип решения этой проблемы описан в обсуждении на stackoverflow, которое я привел в конце вопроса, он же упомянут ultimate_darkness на несколько ответов выше
мб, я что-то не понимаю, но не похоже, что select for update может помочь, вот пример:
start transaction;
select * from transaction order by id limit 1 for update;
select * from transaction order by id limit 1 for update;
rollback;
очевидно, если между двумя запросами select новые данные в таблицу transacton не добавлялись, в выборку в обоих запросах попадет одна и та же запись. но, т.к. все это выполняется в пределах одной транзакции (а именно такая ситуация была в приложении), то никаких ошибок и блокировок не происходит. попытка сделать выборку этой записи из другой сессии, понятное дело, натыкается на блокировку и ждет, пока транзакция не будет завершена, но это не мой случай. хочется еще раз подчеркнуть, все операции, которые я описывал в изначальном вопросе происходили в рамках одной сессии и одной транзакции, поэтому select for update, видимо, не решение. по этим же причинам уровень изоляции SERIALIZABLE не поможет. кроме того, если я правильно понимаю, этот уровень сделает базу ощутимо менее проворной, что тоже не желательно
что касается отдельного поля для версии, это можно сделать, но его придется проверять явно, я правильно понимаю? если да, то это решение в общем-то не лучше того, чтобы просто вытаскивать запись еще раз перед вторым изменением
спасибо, как таковой проблемы сейчас уже нет. решил весьма похожим способом :)
но такие ситуации вполне могут появляться снова, вопрос был по большому счету именно о том, как избежать подобных проблем вообще. остальное — просто для примера.
общее же решение описано неплохо в ссылке на stackoverflow, которую я дописал в конце вопроса, о нем еще упоминает ultimate_darkness на пару ответов ниже
да, спасибо. я в конце вопроса уже после его публикации добавил ссылку на похожий вопрос на stackoverflow. там как раз указывается, что Django ORM не предоаставляет функциональность identity map. если бы предоставлял, то вместе с транзакциями это уже было бы полностью рабочее решение
