Если я ничего не путаю, то внутри 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 на несколько ответов выше
спасибо, как таковой проблемы сейчас уже нет. решил весьма похожим способом :)
но такие ситуации вполне могут появляться снова, вопрос был по большому счету именно о том, как избежать подобных проблем вообще. остальное — просто для примера.
общее же решение описано неплохо в ссылке на stackoverflow, которую я дописал в конце вопроса, о нем еще упоминает ultimate_darkness на пару ответов ниже
да, спасибо. я в конце вопроса уже после его публикации добавил ссылку на похожий вопрос на stackoverflow. там как раз указывается, что Django ORM не предоаставляет функциональность identity map. если бы предоставлял, то вместе с транзакциями это уже было бы полностью рабочее решение
собственно, да, так и есть. проблема в том, что user.account и transaction.account — это разные питонячие объекты, хотя логически они предславляют один и тот же объект БД. поэтому вызывая по очереди user.account.save() и transaction.account.save(), вторая операция может сохранить данные, которые не учитывают изменения, сделанные в первой итерации
