> setattr(model, 'ClassName', NewUser) или Field.contribute_to_class() (или Model.add_to_class())
в прошлом проекте у нас был Model.add_to_class(),
в итоге этих строчек было очень много, тут же еще и методы надо добавлять таким способом, это смотрится как-то совсем ужасно, это совсем не python-way.
> 1. 2. 3.
как-то все это костыльно, да и паттерны-то отличаются, у алхимии Data mapper.
мне интересно можно ли поймать event между получением данных из базы и созданием model instances чтобы добавить к model instances дополнительное поле которое не объявлено никак, а данные для этого поля приходят из дополнительного генерируемого поля в query.
например нам нужно вывести дерево комментариев одним запросом через WITH RECURSIVE ..., level и прочее для комментариев в базе не хранятся, чтобы дерево не пересчитывалось долго (а когда комментариев очень много, то пересчет долгий), level считается на лету, и нам нужно подсчитанный level добавить в инстанс модели.
> шаблон только единожды прочтётся и распарсится, а затем будет просто реднериться
> При этом обвинения в сторону производительности шаблонизатора звучат с уст тех, кто ни разу не разрабатывал проекта с посещаемостью более 1000 уник. в сутки…
хех :) я разрабатывал, и честно говоря шаблоны джанги мне не очень нравятся, и выше я уже писал про ту же отсылку писем например, на jinja2 генериться млн. писем будет гораздо быстрее
> Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy
можно плз подробнее?
> есть масса способов не хранить телефон в профайле, а хранить его в юзере…
можно плз подробнее про расширения для админки? что-то мы смотрели (давно правда) несколько и на тот момент мало что устроило, вдруг что допилили уже )
джанга хороша для 90% случаев, но это не значит что в остальных 10% надо пытаться подогнать ее под работу.
как где-то говорилось «большинство проблем начинается с того, что пытаются использовать инструмент, не предназначенный для этого».
и если грамотно писать, то любой пришедший джангист в проект написанный на Flask'е легко разберется и очень быстро включится в работу.
для алхимии есть готовый extension
не, не надо нам такого счастья )
> Всего на одной модели User?
да, на ней самой
iterator() возвращает просто сырые данные? т.е. инстансы моделей нам самим создавать и заполнять?
> get_comments_with_level
вопрос как заполнять эти дополнительные поля, проходиться отдельным циклом по данным это не айс :)
раньше проверял, была разница.
ну а так есть в сети же тесты тоже
www.askthepony.com/blog/2011/07/django-and-postgresql-improving-the-performance-with-no-effort-and-no-code/
stackoverflow.com/questions/8318999/why-isnt-this-jinja2-template-rendering-faster-than-djangos
в прошлом проекте у нас был Model.add_to_class(),
в итоге этих строчек было очень много, тут же еще и методы надо добавлять таким способом, это смотрится как-то совсем ужасно, это совсем не python-way.
> 1. 2. 3.
как-то все это костыльно, да и паттерны-то отличаются, у алхимии Data mapper.
мне интересно можно ли поймать event между получением данных из базы и созданием model instances чтобы добавить к model instances дополнительное поле которое не объявлено никак, а данные для этого поля приходят из дополнительного генерируемого поля в query.
например нам нужно вывести дерево комментариев одним запросом через WITH RECURSIVE ..., level и прочее для комментариев в базе не хранятся, чтобы дерево не пересчитывалось долго (а когда комментариев очень много, то пересчет долгий), level считается на лету, и нам нужно подсчитанный level добавить в инстанс модели.
> шаблон только единожды прочтётся и распарсится, а затем будет просто реднериться
ну так сам рендер и медленный же.
хех :) я разрабатывал, и честно говоря шаблоны джанги мне не очень нравятся, и выше я уже писал про ту же отсылку писем например, на jinja2 генериться млн. писем будет гораздо быстрее
> Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy
можно плз подробнее?
> есть масса способов не хранить телефон в профайле, а хранить его в юзере…
тоже поясните плз как вы делали?
код закрытый
p.s.
orm и шаблоны как раз-таки отличаются еще как ) но не будем об этом.
почему?
как раз-таки для большей гибкости и максимальной производильности лучше вместо джанговского ORM использовать sqlalchemy / mongo и jinja2
или брать Flask+sqlalchemy/mongo+jinja2+wtforms.
не вижу смысла в djmicro