Ведущие разработчики о будущем Джанго » комментарииhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/2015-05-10T00:42:51.570809-07:00Иван Сагалаев о программировании и веб-разработкеhttp://softwaremaniacs.org/media/sm_org/style/photo.jpgПровёл анализ Django с версии 1.3 до версии 1.8 на "Ведущие разработчики о будущем Джанго"
2015-05-10T00:42:51.570809-07:00Провёл анализ Django с версии 1.3 до версии 1.8https://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-494387Провёл анализ рассылки Python Weekly? там часто можно встретить приложения. Охват получился: Django с версии 1.3 до версии 1.8 Что меня расстроило в 2011 году? Тогда весь запад старался в Django использовать всё, что угодно кроме кода Django. Мне это очень не нравилось и я всё такие решил, что это...
<p>Провёл анализ рассылки Python Weekly? там часто можно встретить приложения.</p>
<p>Охват получился:</p>
<p>Django с версии 1.3 до версии 1.8</p>
<p>Что меня расстроило в 2011 году?</p>
<p>Тогда весь запад старался в Django использовать всё, что угодно кроме кода Django.
Мне это очень не нравилось и я всё такие решил, что это не верный подход и решил для себя, что буду стараться решить всё при помощи чистого Django или Python.</p>
<p>Сейчас же в 2015 году (апрель), когда провёл анализ, запад отказался от идеи применения в Джанго принципа (использовать всё, кроме Джанго).</p>
<p>Все поняли, что сложности ни к чему и чистота кода, читаемось, лёгкость обновления превыше всего.</p>
<p>Это сильно порадовало. </p>
<p>Слова ДЖЕЙКОБА КАПЛАН-МОССА работают на практике, действительно в Джанго включается то, что хотят видеть пользователи.
Это включение в 1,7 South, в 1,8 Джинжу.</p>
<p>Кстати, если посмотреть например вопросы и ответы Хабра, то явно видно, что рунет отстаёт в этом вопросе на те же 4 года.</p>
<p>Поэтому подумайте, если вам кто-то рекомендует какой-то вопрос решить с участие другого языка, поищите библиотеку или посмотрите справку, скорее всего решение будет найдено, а вы сэкономите время.</p>
<p>Читать статью полностью здесь:</p>
<p><a href="http://spb-tut.ru/guest/pages/47/">http://spb-tut.ru/guest/pages/47/</a>protractileaigu на "Ведущие разработчики о будущем Джанго"
2012-02-23T07:45:34.280193-08:00protractileaiguhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-122053Nice write up, thanks for sharing.
<p>Nice write up, thanks for sharing.Андрей Богомолов на "Ведущие разработчики о будущем Джанго"
2011-12-16T15:48:04.292437-08:00Андрей Богомоловhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-106742Можно ли запустить джанго на торнаде или на стеклессе? как можно ставить эти два решения в один ряд? торнадо - это как раз ближе к twsited. Ну да, можно. Но это абсолютно ничего не поменяет, сама работа джанги не станет при этом асинхронной. Если внутри обработки запроса джангой у нас...
<blockquote>
<p>Можно ли запустить джанго на торнаде или на стеклессе? </p>
</blockquote>
<p>как можно ставить эти два решения в один ряд? торнадо - это как раз ближе к twsited.</p>
<blockquote>
<p>Ну да, можно. Но это абсолютно ничего не поменяет, сама работа джанги не станет при этом асинхронной. Если внутри обработки запроса джангой у нас есть внешняя, тяжелая или нестабильная по времени операция, то на ее месте нельзя так просто взять и разрубить обработку.</p>
</blockquote>
<p>если речь идет про stackless и эта внешня вещь умеет кооперативную многозадачность, то можно.</p>
<blockquote>
<p>Работа с БД, как ни странно, это не всегда та область, где нужна асинхронка, далеко не все запросы тяжелые и оверхед, который создаст обработка колбеков, может быть сопоставим с самим запросом, а сложность добавится.</p>
</blockquote>
<p>оверхед от запуска множества процессов или тредов будет больше чем от сохранения стека и вызова колбека, а сложность при использовании stackless или гринлетов не добавится, т.к. стиль написания кода не поменяется (но естественно нужно иметь ввиду что происходит под капотом)</p>
<blockquote>
<p>Малореально полностью обернуть ОРМ в асинхронку</p>
</blockquote>
<p>я конечно не пытался, но не вижу проблемы если честно - сама работа с базой уже будет асинхронная, при этом код самих функций, которые обращаются к вызовам функций бд переписывать не надо - в этом и прелесть гринлетов или stackless. Осталось только саму джангу пускать в uwsgi сервере, который вместо форка создает гринлет.Предок на "Ведущие разработчики о будущем Джанго"
2011-11-28T22:31:33.369312-08:00Предокhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-104694Как и неприятно видеть, что творит ORM при удалении нескольких записей с внешними ключами. Я не люблю когда разработка превращается в танец с бубном и то — То же самое. Это поведение задокументировано (уж не буду тыкать ссылкой). Нужно внимательно читать доку. И для такого поведения есть обоснования.
<blockquote>
<p>Как и неприятно видеть, что творит ORM при удалении нескольких записей с внешними ключами. Я не люблю когда разработка превращается в танец с бубном и то</p>
</blockquote>
<p>— То же самое. Это поведение задокументировано (уж не буду тыкать ссылкой). Нужно внимательно читать доку. И для такого поведения есть обоснования.Предок на "Ведущие разработчики о будущем Джанго"
2011-11-28T21:59:22-08:00Предокhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-104692Почему-то вспомнил http://lurkmore.ru/%D0%93%D0%BE%D0%B2%D0%BD%D0%BE%D0%BA%D0%BE%D0%B4 В Индии с некоторых времен существует практика оценки производительности труда программиста на основе количества написанного кода. Чем больше кода, тем больше программист работает, и, следовательно, выше его оклад. Шустрые индусы быстро сообразили, как обманывать неквалифицированных заказчиков. В результате чего можно встретить подобные шедевры (и это только цветочки!):...
<p>Почему-то вспомнил <a href="http://lurkmore.ru/%D0%93%D0%BE%D0%B2%D0%BD%D0%BE%D0%BA%D0%BE%D0%B4">http://lurkmore.ru/%D0%93%D0%BE%D0%B2%D0%BD%D0%BE%D0%BA%D0%BE%D0%B4</a></p>
<blockquote>
<p>В Индии с некоторых времен существует практика оценки производительности труда программиста на основе количества написанного кода. Чем больше кода, тем больше программист работает, и, следовательно, выше его оклад. Шустрые индусы быстро сообразили, как обманывать неквалифицированных заказчиков.
В результате чего можно встретить подобные шедевры (и это только цветочки!): [скрыть]</p>
</blockquote>
<pre><code>if (true) {
// какой-то код
} else {
// a вот тут чистый profit
}
</code></pre>
<p>Менее очевидный вариант:</p>
<pre><code>if(var)
{
...
}
else if(!var)
{
...
}
else
{
// чистые деньги
}
</code></pre>
<p>Писать много кода - не проблема. Проблема писать мало кода. Очень распространенная проблема. написать лаконичную программу сложнее чем написать большую проблему. Идеал - это года нечего добавить, и нечего отнять.</p>
<p>Призывы "давайте в Джангу напихаем кучу кода" говорят о том, что многие люди не понимают замысла авторов Джанги. И начинают усложнять хоть и простые, но самодостаточные решения, не понимая, как в полной мере можно реализовать простоту, и не понимая отличия между простотой и примитивностью. Часто многословный код бывает более примитивен, чем простой код.Предок на "Ведущие разработчики о будущем Джанго"
2011-11-28T21:48:44-08:00Предокhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-104691чтобы на странице не писать кучу if-ов, а вставить {% check_perm app_name.view_name %}, и права проверялись именно те, что во вьюшке. (Пока что код просто дублируется.) — oeuoeu, Иногда лучше почитать доку https://docs.djangoproject.com/en/dev/topics/auth/#id9 В Джанге, как раз, наоборот, вопрос распределения прав решен очень гибко и правильно, особенно пообъектное распределение прав....
<blockquote>
<p>чтобы на странице не писать кучу if-ов, а вставить <code>{% check_perm app_name.view_name %}</code>, и права проверялись именно те, что во вьюшке. (Пока что код просто дублируется.)</p>
</blockquote>
<p>— oeuoeu, Иногда лучше почитать доку <a href="https://docs.djangoproject.com/en/dev/topics/auth/#id9">https://docs.djangoproject.com/en/dev/topics/auth/#id9</a></p>
<p>В Джанге, как раз, наоборот, вопрос распределения прав решен очень гибко и правильно, особенно пообъектное распределение прав. Не нравится писать бэкенды - подключи django-rules.</p>
<p>Есть только одна точка, которая позволяет сделать все. Нравится много кода на каждый чих, - посмотрите в сторону Джумлы и иже подобное.</p>
<p>pySilver, - ответ на Ваш вопрос. Потому что Zend_Db_Table и близко не валялся с Джанго-ОРМ, потому его костылями и обвешивают. Более мудрые его вообще не используют, а интегрируют Доктрину.Google user на "Ведущие разработчики о будущем Джанго"
2011-10-16T13:26:58.441552-07:00Google userhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-100229меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд) Андрей, я понимаю, что асинхронность это...
<blockquote>
<p>меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд)</p>
</blockquote>
<p>Андрей, я понимаю, что асинхронность это хороший современный тренд, но на мой взгляд переписывание джанги в асинхронном стиле малореализуемый проект.</p>
<p>Можно ли запустить джанго на торнаде или на стеклессе? Ну да, можно. Но это абсолютно ничего не поменяет, сама работа джанги не станет при этом асинхронной. Если внутри обработки запроса джангой у нас есть внешняя, тяжелая или нестабильная по времени операция, то на ее месте нельзя так просто взять и разрубить обработку.</p>
<p>Работа с БД, как ни странно, это не всегда та область, где нужна асинхронка, далеко не все запросы тяжелые и оверхед, который создаст обработка колбеков, может быть сопоставим с самим запросом, а сложность добавится.</p>
<p>Мы имеем не просто тяжелые запросы к БД, а тяжелый ОРМ. Малореально полностью обернуть ОРМ в асинхронку так как в джанге, в соответствии с видением разработчиков, модель часто дергается через render, это означет что уже внутри рендера у нас будет куча колбеков, замыкание на них дополнительной логики это гарантированный хаос, либо мы отвязываем шаблонизатор от работы с моделью, руша всю красоту и функциональность.</p>
<p>Что будет при этом с 3-rd party страшно даже подумать. Даже в идеальном случае скорее всего получится маловразумительный клон джанги с крайне ограниченной функциональностью и сильно проигрывающий изначально асинхронным решениям. При этом очень непопулярный и редко используемый клон.</p>
<p>Если нужна асинхронка и неизбежно использование django, то лучше вывести колбеки на уровень непосредственно обработки, привязав их к какому ни будь асинхронному воркеру на twisted или tornado, который принимают, например, строку запроса к стороннему API и по завершению обращения дергают backurl с передачей ответа обратно в джангу. Если нужен, например, генератор тяжелых отчетов, то таким образом можно дернуть сторонний скрипт, подключенный к модели приложения.Google user на "Ведущие разработчики о будущем Джанго"
2011-10-16T12:42:57.030532-07:00Google userhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-100226После десятка проектов необходимыми и сложными в самостоятельной реализации фичами видятся следующие: Нормальная интеграция модели с системой миграций, например South, лучше вообще включить его в Джангу. Гадать где там возникнет очередная проблема с наследованными классами моделей и т.д. несколько утомительно. Между разработчиками South и Django не хватает взаимодействия. Нормальный механизм...
<p>После десятка проектов необходимыми и сложными в самостоятельной реализации фичами видятся следующие:</p>
<ol>
<li>
<p>Нормальная интеграция модели с системой миграций, например South, лучше вообще включить его в Джангу. Гадать где там возникнет очередная проблема с наследованными классами моделей и т.д. несколько утомительно. Между разработчиками South и Django не хватает взаимодействия.</p>
</li>
<li>
<p>Нормальный механизм дампа и рекавера. Существующий написан левой пяткой никуда не годится. Дамп таблицы с 10.000 записей требует 8гб озу на борту, понятно почему, но непонятно почему это так. Зачем перегонят весь пирог через память? Без этого оснастки и весь связанный с ними механизм крайне ограничен.</p>
</li>
<li>
<p>Шаблонизатор бесшовно работающий как с локальными файлами, так и с шаблонами в базе.</p>
</li>
<li>
<p>Внятный менеджер конфигураций, ну хотя бы как в Tornado, только с возможность разделения конфига для разных приложений и сценариев. Все существующие решения слишком разношерстны и имеют свои проблемы.</p>
</li>
</ol>
<p>Все эти вещи, на мой взгляд требует того, чтобы разработчики джанго взяли вопрос под свой контроль.</p>
<p>Ну и работа над ошибками и временными решениями, например удаление разночтений между поведением модели при операциях из админки и ручным управлением. Обнаруживать не сработавший ondelete крайне неприятно. Как и неприятно видеть, что творит ORM при удалении нескольких записей с внешними ключами. Я не люблю когда разработка превращается в танец с бубном и то, как ведет себя ORM при сколько ни будь сложнымх обращениях к нему - это прямая бубнозависимость. На маленьких проектах это не важно, на больших - принципиально.Андрей Богомолов на "Ведущие разработчики о будущем Джанго"
2011-10-07T04:39:38.609530-07:00Андрей Богомоловhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99356Иван, по поводу ваших слов: В теории должно мешать то, что Джанга рассчитана на работу в синхронной модели, а real-time серверы делают асинхронно обычно. меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и...
<p>Иван, по поводу ваших слов:</p>
<blockquote>
<p>В теории должно мешать то, что Джанга рассчитана на работу в синхронной модели, а real-time серверы делают асинхронно обычно.</p>
</blockquote>
<p>меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд)</p>
<p>тот же вопрос иногда встает при сравнении twisted/tornado c stackless (почему все так тащаться от первых, когда второй выглядит намного удобнее для написания таких приложений), но это уже совсем другая тема...Ivan Sagalaev на "Ведущие разработчики о будущем Джанго"
2011-10-06T03:31:43.881144-07:00Ivan Sagalaevhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99214Заходила! Джейкоб выразился примерно так: "Когда речь заходит про Питон 3, люди обычно указывают на кого-то и говорят, что те их держат. Сначала это были драйверы БД, потом WSGI. Так вот теперь, если вы не заметили, все показывают на нас! Так что настало время наконец сделать это." Ну и собственно:...
<p>Заходила! Джейкоб выразился примерно так: "Когда речь заходит про Питон 3, люди обычно указывают на кого-то и говорят, что те их держат. Сначала это были драйверы БД, потом WSGI. Так вот теперь, если вы не заметили, все показывают <em>на нас</em>! Так что настало время наконец сделать это."</p>
<p>Ну и собственно: <a href="https://code.djangoproject.com/changeset/16742">https://code.djangoproject.com/changeset/16742</a>oleg на "Ведущие разработчики о будущем Джанго"
2011-10-05T21:35:26.624238-07:00oleghttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99186Иван, а про переход Django на Python3, на DjangoCon, речь не заходила? Или про возможные планы?
<p>Иван, а про переход Django на Python3, на DjangoCon, речь не заходила? Или про возможные планы?Ivan Sagalaev на "Ведущие разработчики о будущем Джанго"
2011-10-05T18:09:44.152572-07:00Ivan Sagalaevhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99180pySilver, про real-time внятно не отвечу, я не работал с real-time и не знаю практических проблем. В теории должно мешать то, что Джанга рассчитана на работу в синхронной модели, а real-time серверы делают асинхронно обычно. Но где конкретно там что не сходится — не знаю. А про валидацию коротко не...
<p>pySilver, про real-time внятно не отвечу, я не работал с real-time и не знаю практических проблем. В теории должно мешать то, что Джанга рассчитана на работу в синхронной модели, а real-time серверы делают асинхронно обычно. Но где конкретно там что не сходится — не знаю.</p>
<p>А про валидацию коротко не отвечу, потому что не знаю, что конкретно Рассел имел в виду. У меня к ней есть свои невнятные претензии, но речь не про меня… Постараюсь его порасспросить ещё :-).Ivan Sagalaev на "Ведущие разработчики о будущем Джанго"
2011-10-05T17:14:36.586273-07:00Ivan Sagalaevhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99179Этот вопрос тогда к вам, а не ко мне: я в Rails не смотрел :-).
<p>Этот вопрос тогда к вам, а не ко мне: я в Rails не смотрел :-).demiazz на "Ведущие разработчики о будущем Джанго"
2011-10-05T06:27:16.811197-07:00demiazzhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99130Иван, так уж получилось, что не смотря на то, что работаю Django-разработчиком, но было время на близкое знакомство с Rails 3. Очень интересно было бы узнать ваше мнение, как специалиста, довольно долго разрабатывавшего под Django, по поводу того, не стоит ли чего-нибудь заимствовать у столь быстро и резко развивающихся Rails...
<p>Иван, так уж получилось, что не смотря на то, что работаю Django-разработчиком, но было время на близкое знакомство с Rails 3. </p>
<p>Очень интересно было бы узнать ваше мнение, как специалиста, довольно долго разрабатывавшего под Django, по поводу того, не стоит ли чего-нибудь заимствовать у столь быстро и резко развивающихся Rails 3? Я говорю не про прямое копирование функционала "в лоб", но вообще про взятие идей, и адаптации к Django.</p>
<p>P.S. Вопрос не холивара ради, как бы холиварно он не звучал. pySilver на "Ведущие разработчики о будущем Джанго"
2011-10-04T18:43:23.127150-07:00pySilverhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99080Иван, поясните пжлста 2 момента: сейчас Джанго не умеет real-time веб правильно, но тут WSGI не даст нам переделать архитектуру Что подразумевается под real-time web? Чего не хватает в джанге? Большая часть ядра Джанго, вообще-то, довольно неплоха. Да, у нас были определённые ошибки — например, валидация в моделях — но...
<p>Иван, поясните пжлста 2 момента:</p>
<blockquote>
<p>сейчас Джанго не умеет real-time веб правильно, но тут WSGI не даст нам переделать архитектуру</p>
</blockquote>
<p>Что подразумевается под real-time web? Чего не хватает в джанге?</p>
<blockquote>
<p>Большая часть ядра Джанго, вообще-то, довольно неплоха. Да, у нас были определённые ошибки — например, валидация в моделях — но в целом всё хорошо.</p>
</blockquote>
<p>Почему валидация в модели дурной тон?</p>
<p>Я всего пару месяцев работаю плотно с django, пришел из мира PHP (Zend Framework), неудобством для меня является некоторое упрощение абстракции в django т.е. view напрямую общается с моделями и менеджерами. Это упрощает разработку согласен, но для большого проекта лично мне непривычно общатся напрямую с ORM, при изменениях приходится менять 10 мест, вместо одного. </p>
<p>В Zend Framework я обычно строил Service Layer находящийся над Data Layer - валидация происходила именно в сервисном слое, вьюшки общались только с сервисным кодом. Грубо говоря Service Layer это бизнес логика, ему не интересно откуда пришел запрос и как хранятся данные, но он знает как их валидировать и интерпретировать.</p>
<p>Приятной плюшкой этого подхода является простота выставление внешнего API которое сразу получает валидацию и набор методов работы с данными. </p>
<p>Но пока что ни одного django проекта с Service Layer я не видел, и кажется мне это не спроста. Почему так не делают?Ivan Sagalaev на "Ведущие разработчики о будущем Джанго"
2011-10-04T09:54:19.317262-07:00Ivan Sagalaevhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99058Вряд ли Володя спрашивал про термин "из коробки". Рискну предположить, что речь о том, что поскольку термин "NoSQL" означает очень разные решения, что его невозможно "поддержать из коробки". Обычно люди под "NoSQL" подразумевают одну только MongoDB.
<p>Вряд ли Володя спрашивал про термин "из коробки". Рискну предположить, что речь о том, что поскольку термин "NoSQL" означает очень разные решения, что его невозможно "поддержать из коробки". Обычно люди под "NoSQL" подразумевают одну только MongoDB.profiles.google.com/vlad.sirenko на "Ведущие разработчики о будущем Джанго"
2011-10-04T09:13:38-07:00profiles.google.com/vlad.sirenkohttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99054Из коробки: # aptitude install python-django A не из коробки, те как сейчас: $ hg clone https://bitbucket.org/wkornewald/django-nonrel
<p>Из коробки:</p>
<pre><code># aptitude install python-django
</code></pre>
<p>A не из коробки, те как сейчас:</p>
<pre><code>$ hg clone https://bitbucket.org/wkornewald/django-nonrel
</code></pre>Вап на "Ведущие разработчики о будущем Джанго"
2011-10-04T08:10:42.428293-07:00Вапhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99050Есть некоторые моменты, которые мне в Django непонятны. Например, почему в PositiveIntegerField можно записать отрицательное значение. Или почему иногда генерируется невалидный для некоторых баз запрос(например, подзапрос с LIMIT и OFFSET для MySQL будет неправильным). Поэтому в будущих релизах хотелось бы увидеть более полную и подробную документацию и уменьшение количества неочевидных...
<p>Есть некоторые моменты, которые мне в Django непонятны. Например, почему в PositiveIntegerField можно записать отрицательное значение. Или почему иногда генерируется невалидный для некоторых баз запрос(например, подзапрос с LIMIT и OFFSET для MySQL будет неправильным).
Поэтому в будущих релизах хотелось бы увидеть более полную и подробную документацию и уменьшение количества неочевидных вещей.http://vapask.yandex.ru на "Ведущие разработчики о будущем Джанго"
2011-10-04T07:55:10-07:00http://vapask.yandex.ruhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99049Возможно это проще решить с NoSQL, но ОРМ должен быть поставлен под контроль, а именно под version control. South разве не решает поставленную задачу?
<blockquote>
<p>Возможно это проще решить с NoSQL, но ОРМ должен быть поставлен под контроль, а именно под version control.</p>
</blockquote>
<p>South разве не решает поставленную задачу?aoeuaoeu на "Ведущие разработчики о будущем Джанго"
2011-10-04T03:48:24.558657-07:00aoeuaoeuhttps://softwaremaniacs.org/blog/2011/10/03/core-devs-on-future/#comment-99027Чтобы ОРМ на нём работал. Мне, когда я начинаю новый проект или делаю маленькую страничку, ПГ не нужен. Да и в Монге сейчас индексация очень хорошо работает.
<p>Чтобы ОРМ на нём работал. Мне, когда я начинаю новый проект или делаю маленькую страничку, ПГ не нужен. Да и в Монге сейчас индексация очень хорошо работает.