Здравствуйте, Cyberax, Вы писали:
C>Кто-нибудь активно использовал сабж? Какие отзывы?
C>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого
C>PS: если кому-то в Киеве интересно поработать на проекте с Python+Django — обращайтесь ко мне.
Используем. Имеем несколько сервисов на нем. Готовыи к выходу следующий. Минус по сути один — как и при использовании любого фреймворка присутсвует ощущение что тобой упраляет нивидимая рука. Иногда это мещает.
Здравствуйте, Cyberax, Вы писали:
C>Кто-нибудь активно использовал сабж? Какие отзывы?
вроде, Roman Odaisky пользует..
я тоже буду активно использовать через пару недель, когда передам работу над текущим проектом в другие заботливые руки..
C>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого
первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
кроме того:
— питон 3к не поддерживается
— не очень изящно выглядят куски кода в шаблонах страниц (хотя мне всё равно, я в танке)
— еще не всё переведено на http://cargo.caml.ru/djangobook/
Здравствуйте, neFormal, Вы писали:
F>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
А поделись типичной задачкой где надо несколько баз сразу иметь?
Здравствуйте, neFormal, Вы писали:
C>>Кто-нибудь активно использовал сабж? Какие отзывы? F>вроде, Roman Odaisky пользует..
Спасибо, попинаю его
C>>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого F>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно?
F>кроме того: F>- питон 3к не поддерживается
Это я смотрел, там просто по мелочам много чего. Фигня.
F>- не очень изящно выглядят куски кода в шаблонах страниц (хотя мне всё равно, я в танке)
Это как раз удобная фича — в случае чего можно при необходимости хак вставить.
F>- еще не всё переведено на http://cargo.caml.ru/djangobook/
Пофиг, все в команде на английском читают.
Здравствуйте, Курилка, Вы писали:
F>>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался.. К>А поделись типичной задачкой где надо несколько баз сразу иметь?
1. я хочу, чтобы аппликухи из джанги писались в разные базы (не физические машины, а database в СУБД), т.к. не хочу хлама из таблиц в одной базе..
2. я подозреваю, что будет слишком много обращений к базе, поэтому предполагаю разносить данные по нескольким машинкам.. ну, кроме того, я не углублялся пока в эту тему, возможно можно будет и проще поступить..
3. ну и репликация БД, которая мне вроде бы не нужна
хотя с другой стороны.. у меня будут накапливаться неактивные объекты, которые надо будет складывать в "холодильник".. вполне возможно, что "холодильник" будет находиться на отдельной неторопливой машинке..
Здравствуйте, Cyberax, Вы писали:
C>>>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого F>>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался.. C>Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно?
нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку..
C>Это как раз удобная фича — в случае чего можно при необходимости хак вставить.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Cyberax, Вы писали:
C>>>>Планируем на нём запустить небольшой пилотный проект. Хотелось бы заранее узнать что в Django плохого F>>>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался.. C>>Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно?
F>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку..
Репликация? Так есть приложения для MySQL с репликами. Уверен, можно и под другие бекэнды адаптировать.
Здравствуйте, Daevaorn, Вы писали:
F>>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку.. D>Репликация? Так есть приложения для MySQL с репликами. Уверен, можно и под другие бекэнды адаптировать.
я пока не буду строить из себя профи ( ), но из того, что я начитал в интернетах: репликация — это не то, чего я хочу..
я хочу, чтобы часть клиентов обрабатывалось с одной БД (физической железки), часть с другой, а остальные с третьей.. нагрузка, видимо будет зависеть от того, насколько косячно я спроектирую БД..
PS: а под джангу есть несколько "патчей" для прикручивания репликации и просто для поддержки нескольких баз.. у них на сайте есть линки(местами нерабочие)..
PPS: кстати, можно в некоторых случаях разные группы данных хранить в разных СУБД.. например, в mysql и oracle одновременно.. mysql под сайт/форум/етк, а oracle для каких нибудь промышленных данных, которые пишутся, например, со станков.. и ко всему этому есть web-доступ
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Daevaorn, Вы писали:
F>>>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку.. D>>Репликация? Так есть приложения для MySQL с репликами. Уверен, можно и под другие бекэнды адаптировать.
F>я пока не буду строить из себя профи ( ), но из того, что я начитал в интернетах: репликация — это не то, чего я хочу.. F>я хочу, чтобы часть клиентов обрабатывалось с одной БД (физической железки), часть с другой, а остальные с третьей.. нагрузка, видимо будет зависеть от того, насколько косячно я спроектирую БД..
Да. Это называет шардинг. Репликация по простому — это когда дынные дублируются на разных нодах, а шардинг когда разделяются.
F>PS: а под джангу есть несколько "патчей" для прикручивания репликации и просто для поддержки нескольких баз.. у них на сайте есть линки(местами нерабочие).. F>PPS: кстати, можно в некоторых случаях разные группы данных хранить в разных СУБД.. например, в mysql и oracle одновременно.. mysql под сайт/форум/етк, а oracle для каких нибудь промышленных данных, которые пишутся, например, со станков.. и ко всему этому есть web-доступ
Для репликаций есть production ready приложение — mysql_replicated.
Здравствуйте, neFormal, Вы писали:
C>>Несколько баз — это необходимость рапределённого коммита для корректной работы. Оно тебе нужно? F>нет, мне надо более удобно и красиво складывать данные + снижать нагрузку на основную машинку..
Если тебе придётся писать в несколько баз одновременно => привет распределённым транзакциям!
C>>Это как раз удобная фича — в случае чего можно при необходимости хак вставить. F>*поперхнулся*
Зато про войну.
Здравствуйте, Daevaorn, Вы писали:
D>Здравствуйте, neFormal, Вы писали:
F>>я пока не буду строить из себя профи ( ), но из того, что я начитал в интернетах: репликация — это не то, чего я хочу.. F>>я хочу, чтобы часть клиентов обрабатывалось с одной БД (физической железки), часть с другой, а остальные с третьей.. нагрузка, видимо будет зависеть от того, насколько косячно я спроектирую БД..
D>Да. Это называет шардинг. Репликация по простому — это когда дынные дублируются на разных нодах, а шардинг когда разделяются.
Точнее именно та схема которую вы опислаи больше подходит как раз под репликации. Когда просто есть несколько баз, но них консистентный массив данных всей системы.
Здравствуйте, neFormal, Вы писали:
F>первая проблема, которую я увидел — по дефолту используется только одна база, что для меня выглядит плохо.. можно прикрутить несколько, но это связано (как мне сказали) с определенными трудностями, до которых я пока не добрался..
Единственный правильный вариант прикручивать несколько баз к одному приложению — это все-таки работать с репликами. Рассмотрим один из вариантов работы с БД некоего универсального веб-приложения: Клиент читает данные. Если они разнесены по нескольким базам, то необходимо передать нужные запросы в базы, дождаться пока они все выполнятся, и потом собрать и показать клиенту.
Overhead на ожидание зачастую сводит на ноль все преимущества разнесения данных на разные базы. Я не говорю уж о том, что не будет выполняться никакой оптимизации.
Клиент модифицирует данные. Стандартная практика в любых серьезных веб-приложениях (в Django-админке это встроено) — это вести аудит операций с данными. Если все разнесено по разным базам, то необходимо вести аудит либо в каждой базе, либо делать единый аудит, и тогда тоже придется как-то делать очередь запросов, чтобы аудит был корректен. Обычно данные все-таки имеют взаимосвязи, поэтому последний вариант предпочтительнее в большинстве случаев. Что опять-таки не добавляет плюсов в копилку разнесения данных по разным БД.
Однако, конечно, репликации не всегда применимы. Тогда я вижу только два варианта: Для каждой базы использовать свое приложение, а разруливать фронт-енд веб-сервером.
Использовать Data Grid. Но это уже совершенно другой отдельный вопрос, и здесь всякие питоны с джангами уже совершенно не удел. Welcome to Enterprise World!
Могу еще порекомендовать ссылку на Django book: Chapter 20: Deploying Django. Там есть раздел "Scale", изучите его, может найдете для себя что-то интересное.
F>кроме того: F>- питон 3к не поддерживается
Как минимум в py3k поменяли все строки полностью на юникодные. Это затрагивает очень много кода в Django, т.к. мощная работа со строками — неотъемлимая часть любого RESTful фреймворка. Также были некоторые изменения в модели метапрограммирования, и это тоже накладывает свой отпечаток.
Так что как обычно, сначала будет переход на 2.6 (возможно к началу следующего года уже все будет готово), и только потом на 3k (это скорей всего 2010 и позже). Хотя в последние годы работа над Django очень убыстрилась, так что возможно все будет готово быстрее.
F>- не очень изящно выглядят куски кода в шаблонах страниц (хотя мне всё равно, я в танке)
Код в шаблоны вообще нельзя встраивать, а то что есть — это вынужденный минимум, чтобы обеспечить хоть какую-то манипуляцию над данными в шаблонах.
Никто, конечно, не мешает писать свои фильтры и теги. Ну или на крайний случай, прикрутить другой template-движок.
Хотя лично я целиком поддерживаю разработчиков Django, что они сделали такой убогий template-engine — если бы он был побогаче (как, например, Genshi), то у разработчиков был бы большой соблазн нарушить MVT паттерн, и в итоге шаблоны превратились бы в PHP-лапшу с синтаксисом питона.
F>- еще не всё переведено на http://cargo.caml.ru/djangobook/
Сейчас встроенная документация в Django очень и очень крутая — в принципе, ничего шикарнее я в своей жизни не видел. Django book уже нужен только начинающим.
Здравствуйте, Cyberax, Вы писали:
C>Кто-нибудь активно использовал сабж? Какие отзывы?
Активно работаем с Django уже года два.
Из хорошего — все круто Если не лезть в админку, то код пишется на ура. ORM, интернационализация, шаблоны, юнит-тестирование — все красиво и приятно.
Из плохого — в основном все проблемы с админкой. Она недостаточно гибкая в плане модификации и интернационализации. Нельзя прикрутить полностью другой бэкэнд для аутентификации и авторизации пользователей.
Есть конечно что-то еще, но прям сейчас в голову не приходит. Может при ответах на наводящие вопросы скажу больше.
Вообще, я планирую написать в ближайшее время сравнительный обзор всех современных "Agile" фреймворков: Django, RoR, Grails, Perl Catalyst, но пока не могу изыскать времени. Там бы я рассмотрел все плюсы и минусы.
Здравствуйте, Nuald, Вы писали:
N>Из плохого — в основном все проблемы с админкой. Она недостаточно гибкая в плане модификации и интернационализации. Нельзя прикрутить полностью другой бэкэнд для аутентификации и авторизации пользователей.
а почему свою не написать?. какие неоспоримые преимущества есть у дефолтной админки?.
N>Есть конечно что-то еще, но прям сейчас в голову не приходит. Может при ответах на наводящие вопросы скажу больше.
Здравствуйте, neFormal, Вы писали:
N>>Из плохого — в основном все проблемы с админкой. Она недостаточно гибкая в плане модификации и интернационализации. Нельзя прикрутить полностью другой бэкэнд для аутентификации и авторизации пользователей.
F>а почему свою не написать?. какие неоспоримые преимущества есть у дефолтной админки?.
Замучишься свою писать. Просто укажу на некоторые подводные камни:
— автогенерация форм (т.е. нужно делать интроспекцию классов и для полей генерировать соответствующие контролы), особенно много заморочек с ManyToManyField;
— валидация данных (это не сложно, но тоже нужно потратить время);
— аудит работы с данными, история изменений (опять интроспекция и какое-то время на реализацию);
— аутентификация и авторизация пользователей (нехилый пласт работ);
— сортировки, поиски и фильтрации (здесь и во встроенной админке не все хорошо, но какой-то базовый минимум все-таки предоставляется).
Т.е. чтобы повторить админку Джанго, придется сильно постараться и потратить немало времени. Конечно, если админка минимальная, и модели простые, то задача сильно упрощается. Если же нет цели вообще использовать админку, тогда и говорить не о чем — в некоторых случаях (например, при разработке вики-подобных сайтов) админка вообще не нужна.
F>а всё ли хорошо с i18n?. легко ли оно делается?.
Достаточно легко в линуксе и юникс-подобных средах. Просто для интернационализации используется стандартная unix-функция gettext(), и под виндами надо ставить какие-то библиотеки, чтобы работали команды makemessages и compilemessages. Возможно, после релиза Django 1.0 все стало попроще, но я не знаю — виндой у нас никто не пользуется.
Если не касаться админки, то интернационализация делается легким движением руки — просто где надо расставляешь теги в шаблонах и вызовы функций в коде. В документации все сказано, и приведены примеры.
Здравствуйте, Nuald, Вы писали:
N>Т.е. чтобы повторить админку Джанго, придется сильно постараться и потратить немало времени. Конечно, если админка минимальная, и модели простые, то задача сильно упрощается. Если же нет цели вообще использовать админку, тогда и говорить не о чем — в некоторых случаях (например, при разработке вики-подобных сайтов) админка вообще не нужна.
А можно ли сделать так, чтобы можно было делать для групп дополнительные уровни?
Т.е. у нас будет 10 клиентов, и у каждого клиента свой набор групп. Т.е. пользователь из группы "admin" у клиента "А" не должен быть админом у клиента "Б".
Я так посмотрел — надо расширять класс Group. Можно ли это сделать?
N>Если не касаться админки, то интернационализация делается легким движением руки — просто где надо расставляешь теги в шаблонах и вызовы функций в коде. В документации все сказано, и приведены примеры.
Ага, в админке интернационализация глючная. Например, поддерживается всего одна форма множественного числа (в русском их три).
Здравствуйте, Cyberax, Вы писали:
C>А можно ли сделать так, чтобы можно было делать для групп дополнительные уровни? C>Т.е. у нас будет 10 клиентов, и у каждого клиента свой набор групп. Т.е. пользователь из группы "admin" у клиента "А" не должен быть админом у клиента "Б". C>Я так посмотрел — надо расширять класс Group. Можно ли это сделать?
Расширить можно любой класс, но будет ли это работать — другой вопрос. Мы решали такого рода задачи другим способом: Отнаследовали от встроенного класса admin собственные классы, каждый из которых реализовывал собственную логику админского сайта.
URLConf переписали таким образом, чтобы в зависимости от группы пользователя или его наименования шел редирект на собственную админку.
Зарегистрировали модели в нужных админках.
В вашем случае, если вы будете переписывать группы, также придется наследоваться от встроенного класса admin, и переписывать URLConf-ы, т.к. зарегистрировать другой класс для групп во встроенной админке вряд ли получится.
Еще как вариант, можно добавить профили для пользователей, и там ввести собственную систему групп. Но опять-таки придется делать собственные классы для админских сайтов.
Я немного эту тему осветил у себя в блоге — Adding security features to Django projects, однако не упоминал там модификацию админки. Если есть желание узнать подробности о вышеприведенном механизме, могу накидать статью.
Здравствуйте, Nuald, Вы писали:
N>В вашем случае, если вы будете переписывать группы, также придется наследоваться от встроенного класса admin, и переписывать URLConf-ы, т.к. зарегистрировать другой класс для групп во встроенной админке вряд ли получится.
Ну есть ещё рабоче-крестьянский метод — импортировать админку в проект и там напрямую поменять. Только вот некрасиво.
N>Еще как вариант, можно добавить профили для пользователей, и там ввести собственную систему групп. Но опять-таки придется делать собственные классы для админских сайтов.
Хочется по минимуму обойтись текущей админкой — она только для администраторов сайта нужна будет, для пользователей всё равно свой интерфейс рисовать будем.
N>Я немного эту тему осветил у себя в блоге — Adding security features to Django projects, однако не упоминал там модификацию админки. Если есть желание узнать подробности о вышеприведенном механизме, могу накидать статью.
Как пользоваться security более-менее понятно...
Кстати, а есть в Django аналог Spring WebFlow? Т.е. диалог из нескольких страниц, наподобии wizard'а, чтоб ещё нормально кнопку back поддерживал?
Кстати, а что с Ajax'ом? Есть ли прозрачный form submit и обновление страницы (т.е. чтоб оно прозрачно присылало изменённые части DOM-дерева)?
Если не лезть в админку, то код пишется на ура. ORM, интернационализация, шаблоны, юнит-тестирование — все красиво и приятно.