После восьми месяцев разработки вышла (https://www.djangoproject.com/weblog/2017/apr/04/django-111-.../) стабильная версия web-фреймворка Django 1.11 (https://docs.djangoproject.com/en/1.11/releases/1.11/), написанного на языке Python и предназначенного для разработки веб-приложений. Кроме того выпущены (https://www.djangoproject.com/weblog/2017/apr/04/security-re.../) корректирующие обновления для прошлых веток Django 1.10.7, 1.9.13 и 1.8.18, в которых устранены уязвимости, которые могут привести к осуществлению XSS-атак (межсайтовый скриптинг) через организацию скрытых редеректов запросов.
Ветка Django 1.11 отнесена к категории выпусков с длительным сроком поддержки, для которых обновления выпускаются на протяжении трёх лет. Ветка 1.10 будет поддерживаться до декабря 2017 года, LTS-ветка Django 1.8 до апреля 2018 года.Ключевые улучшения (https://docs.djangoproject.com/en/1.11/releases/1.11/):
- Новая модель (https://docs.djangoproject.com/en/1.11/releases/1.11/#class-...) создания индексов для СУБД, основанная на использовании классов. Классы для создания индексов представлены в новом модуле django.db.models.indexes - Index для индексов b-tree, GinIndex для GIN (https://www.postgresql.org/docs/current/static/gin.html) (Generalized Inverted Index), BrinIndex для BRIN (https://www.postgresql.org/docs/current/static/brin-intro.html) (Block Range Index);- Средства (https://docs.djangoproject.com/en/1.11/releases/1.11/#templa...) отрисовки виджетов через систему шаблонов (https://docs.djangoproject.com/en/1.11/ref/forms/renderers/), позволяющих упростить адаптацию виджетов под свои потребности без необходимости правки кода на языке Python;
- Возможность (https://docs.djangoproject.com/en/1.11/releases/1.11/#subque...) определения подзапросов к СУБД, средствами прослойки ORM. Подзапросы оформляются при помощи новых выражений
Subquery и Exists, для доступа к полям другого запроса добавлен класс OuterRef;
- Добавлена поддержка Python 3.6. Как и раньше поддерживаются ветки
Python 2.7, 3.4 и 3.5;URL: https://www.djangoproject.com/weblog/2017/apr/04/django-111-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=46335
самый толерантный фремворк https://github.com/django/django/pull/2692
Бедняги.
Я давно так не смеялся, спасибо :)
Я так понимаю, даже комментировать не нужно. Разработчики все сами сказали.
Шикарно:For example, your avatar is red. Red, like communism. You should use a black and white color. Oh no, that's linked to racism too. Well. Let's remove colors, too, then ? ;)
Кажется, что туда троллей немало понабежало.
Ну и где толпы крутых программеров, которые еще лет 10 назад всем доказывали, что за питоном/джангой большое будущее? В комментариях хоть шаром покати.
В коучинге, рассказывают как делать стартапы. А ты думал, они программированием будут зарабатывать?
А что комментировать? кто работает - тот работает. Есть куча веб фреймворков, от турбогира до мини-вишенки, отдельно именно по джанго с ума толпы не сходят. Да, скорее всего самый массовый, и что? Корпоративными подходом - как дальше строчат на 2,7 так и строчат дальше.. Ну поддерживает он счас 3.6. Отлично. Никто не против. Браво!
Ну туториал на сайте для питона третьего.
>Возможность определения подзапросов к СУБД, средствами прослойки ORM. Подзапросы оформляются при помощи новых выражений Subquery и Exists, для доступа к полям другого запроса добавлен класс OuterRef;Чего только люди не придумают, лишь бы не пользоваться SQL. Впрочем, браво. Раньше у меня были хоть какие-то аргументы о том, что ORM в Django не умеет кое-что, что умеет SQL. Теперь у меня этих аргументов почти нет. Не знаю, UNION уже поддерживается в ORM или ещё нет? Осталась только одна проблема - некоторые люди, использующие ORM, часто считают, что знания SQL им не нужны. Но чтобы понять подзапросы в ORM Django, наверное надо понять сначала, как они пишутся в SQL.
Как вообще можно работать с базой данных, не зная как она работает и не зная хотя бы основ SQL... загадка.
Чтоб работать с ORM, знать нужно сильно БОЛЬШЕ, чем голый SQL. Как минимум, понимать, что такое ООП, как работают модели в данном конкретном случае и т.д. (Если не рассматривать простейшие случаи, конечно.) Как бонус получаешь увеличение скорости разработки, гибкость кода и резкое уменьшение количества ошибок.
"Чтоб работать с ORM, знать нужно сильно БОЛЬШЕ, чем голый SQL"+100500! На опеннете ещё остались адекваты :)
Сейчас "просто DBA" вымирают как динозавры, т.к. их убогий 50летный SQL уже ни в какие ворота не лезет и помощи от DBA разрабу обычно никакой.
Не поговорю уж про "бОльшая часть проектов на NOSQLе давно". Если бы не изобрели ORM реляционные СУБД в актуальных проектах бы сейчас вообще не использовали. Но с никакой скоростью РСУБД, увы, никакие припарки не помогают. Так что процесс умирания таки идёт...