Выпуск версии Django 1.6

Замечательно, но когда они придумают нормальный способ конвертации поддерживаемых баз данных? С помощью dumpdata/loaddata с некоторыми моделями не получается.

Часто ведь может такое требоваться. Разрабатываешь сайт, используешь sqlite, потом переносишь на сервер, где будешь использовать mysql или др. Не создавать же данные с нуля.

Плюсую, долго мучался с этим.

Зато в 1.7 обещают миграции, можно будет наконец выбросить south. Глядишь, и перенос потом запилят нормальный.

в 1.7 обещают миграции

они до сих пор ниасилили их?! после Rails Django таким древним гуано видится…

// let's flame begin!

Не в коробке миграции есть давно. В коробке будут с 1.7 уже смержено в мастер.

Есть в south, но нет в самой джанге. Я пока не смотрел, чем они будут отличаться и зачем они запиливают это в core.

Автор юга пишет с ноля, более лучший код и дизайн, киллер фича - сквош миграций в одну, для тех кому надоедает ждать бутстрапа тестраннера :)

Старые миграции будет поддерживать, или можно будет выбросить?

Правда, я их все равно уже накатил :3

Старые == южные? Там все более по другому устроено, так что не думаю.

Имеет смысл переезжать на Django с Rails? Есть какие-то killer-features?

Если не прикипает от рельсов, не думаю что зайдет. Из киллер фич язык программирования в качестве языка программирования и недоадминка. И не так много магии.

Ясно, спасибо.

Бинарное поле для моделей, позволяющее хранить в базе двоичные данные

Очень интересно, этого недостает местами и временами.

На 3.0-то уже работает? Я просто не слежу

// let's flame begin!

Купи себе учебник английского.

А когда я так жирно вбрасывал, с меня снимали скор :(

Нафиг вообще использовать эту лишнюю сущьность к БД, когда есть RAW-запросы?

1.5 вроде работало уже, но не все «популярные» модули работали на нем, то есть полноценно - не работает.

Может что-то изменилось?

Часто ведь может такое требоваться

вообще не нужно никому и никогда такое.

кроме того адекватное конвертации вы не получите, я бы никогда не надеялся, что мои данные какой-то Вася Разработчик сконвертирует безопасно и без проблем, используйте одну БД.

вообще не нужно никому и никогда такое.

Чушь несёшь. Пример я уже привёл. Разрабатываю я, например, сайт на своём компьютере. Используется sqlite. Даже если я не разрабатываю какой-то свой движок, а просто взял например django-cms, написал шаблонов и наполняю сайт страницами. Когда всё будет готово, я перенесу на хостинг.

используйте одну БД.

Ага, sqlite.

Думается мне что это будет тяжеловато нормально сделать. Я не так давно пытался перенести данные из небольшой базы с mysql на postgresql и у меня это так полностью и не получилось. Все равно приходится лезть и что-то править руками. Хотя возможно и то что у меня руки кривые

По идее, если действовать строго в рамках ORM, то проблем быть не должно, однако, они могут быть: например, SQLite не контроллирует, действительно ли длина строки, которую пишут в varchar(x) меньше x, а другие базы контроллируют, это самый частый баг при переносе, хотя, если самому делать необходимую валидацию, то проблем не будет.

Однако, соглашусь с теми, кто говорит здесь «не нужно».

Уже Python3 или еще нет?

Допишите пожалуйста в новость, что этот выпуск посвящается Малькольму.

Выпуск версии Django 1.6 (комментарий)

Аноним, сходи по ссылке:

Django 1.6, like Django 1.5, requires Python 2.6.5 or above. Python 3 is also officially supported. We highly recommend the latest minor release for each supported Python series (2.6.X, 2.7.X, 3.2.X, and 3.3.X).

Постоянные соединения с базой данных. По умолчанию отключено (соединения закрываются по окончанию запроса, как в более ранних версиях). Для включения параметру CONN_MAX_AGE нужно присвоить значение None.

Т.е. при обработке http запроса каждый раз заново будет устанавливаться соединение с БД? Зачем это нужно?

Наоборот. Будут использоваться уже открытые соединения. А раньше на каждый запрос в БД устанавливалось новое.

ЯННП!
В новости написано:

Постоянные соединения с базой данных. По умолчанию отключено

Так отключено или нет?

Появилась новая функция, постоянные соединения. В 1.5 и ранее ее не было, т.е. она была отключена. Сейчас по умолчанию она тоже отключена для совместимости, но можно включить.

Постоянные соединения с базой данных
Бинарное поле для моделей, позволяющее хранить в базе двоичные данные

Есть в Java EE с хрен знает какого года. Почему так медленно?

Автокоммит на уровне базы данных включен по умолчанию.

Опасная фича, поощряет небрежное отношение к транзакциям. Кто-нибудь может объяснить, зачем добавили?

Есть в Java EE с хрен знает какого года. Почему так медленно?

Потому что джаву пишет корпорация, а джангу некоммерческая организация.

Кто-нибудь может объяснить, зачем добавили?

Оно и раньше так работала, только не на уровне БД, а на уровне фреймворка создавались и коммитились транзакции на каждый запрос. Просто перенесли это в БД для скорости.

Т.е. только сейчас появилась фича которая в рейс была с первой версии? Много видел утверждений что джанго работает быстрее рельс, как оно может работать быстрее если каждый раз конектится к БД заново?

Много видел утверждений что джанго работает быстрее рельс, как оно может работать быстрее если каждый раз конектится к БД заново?

Наверное, коннект к БД не самое медленное в джанге :)

Но это мое рандомное мнение, я не видел рельсы и не сравниваю с ними.

Много видел утверждений что джанго работает быстрее рельс,

Потому что питон быстрее руби. Про руби вообще говорят что он самый медленный из всех скриптовых языков.

Оно и раньше так работала, только не на уровне БД, а на уровне фреймворка создавались и коммитились транзакции на каждый запрос. Просто перенесли это в БД для скорости.

Я про то, что это в принципе не нужная фича. Границы транзакции должны быть видны явно, иначе легко нахерачить код, который половину дел делает в одной транзакции, половину в другой, а по смыслу всё должно в случае факапа откатиться. В итоге лирический герой узнает об ошибке, только когда этот самый факап произойдёт на продакшене.

Как быстро на относительно сложных проектах поднимается django окружение? У меня сейчас в текущем rails проекте

time rails runner 'puts 1 + 1'
2

real	0m5.194s
user	0m4.484s
sys	0m0.660s

У django на больших проектах цифры такие же? Я конечно понимаю что это зависит от многих факторов. Но все же, есть ли ощутимая пауза в django при запуске тестов для относительно больших проектов?

Не знаю, у меня проект небольшой.

Что то особой быстроты питона я не заметил http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=p...

Но все же, есть ли ощутимая пауза в django при запуске тестов для относительно больших проектов?

Если вычесть поднятие тестовой базы - не особо.

vagrant@vagrant-ubuntu-raring-64:/xxx/ time python manage.py syncdb

real	0m0.703s
user	0m0.300s
sys	0m0.204s

Это в виртуалке, на вялом макбуке, с хождением в базу.

Это скорее рельсы и средний по больнице дсл обмазаный идеоматический руби код медленнее чем питон.

А Mojolicious лучше Поздравляю питонистов.

The isolation level can be customized under PostgreSQL.

Оно и раньше так работала, только не на уровне БД, а на уровне фреймворка создавались и коммитились транзакции на каждый запрос. Просто перенесли это в БД для скорости.

Ни разу не также, раньше транзакция была на каждый HTTP-запрос, а теперь — на каждый SQL-запрос, т.е. если вьюшка упала где-то посередине, в базе останутся следы жизнедеятельности первой половины вьюшки. Понятно, что так быстрее, но у меня очень смешанные чувства по поводу этого нововведения, по-моему, зря.

Ни разу не также, раньше транзакция была на каждый HTTP-запрос

Django’s default behavior is to run with an open transaction which it commits automatically when any built-in, data-altering model function is called. For example, if you call model.save() or model.delete(), the change will be committed immediately.

Для request-based транзакций и раньше нужно было добавлять TransactionMiddleware.

это «холодный» запуск?

нет

Нафиг вообще использовать эту лишнюю сущьность к БД, когда есть RAW-запросы?

RAW-запросы это не комильфо.

И правда, я думал, оно там по умолчанию. Тем не менее, теперь и оно deprecated.

Но вообще, фиг с ним, обычно вьюшек, где что-то такое сложное творится не много, и декоратор на них повесить не сильно сложно.