"2070" — это магические цифры, которые для джангиста означают номер давнего, многострадального и считавшегося некоторыми обреченным тикета, который отвечает за то, чтобы Джанго загружаемые в нее через веб файлы не грузила целиком в память.

И вот буквально вчера лед тронулся!

Помимо того, что меня это радует в принципе, у меня есть еще и личный мотив. Для злорадных потрясаний пальцем с воплями "а я же говорил"! Суть в том, что этот тикет был открыт вместо более раннего тикета с моим патчем, который хоть и был недоработан, но фиксил ядро проблемы. Автор нового тикета сказал, что этого недостаточно и затолкал в один патч аж три совершенно разноуровневые вещи:

И вот тогда я долго пытался втолковать, что такую патч-бомбу никто не сможет нормально отсмотреть, и следовательно шансов на включение в транк у нее почти нет. Плюс из-за непродуманной архитектуры по ходу 2 лет существования тикета его преследуют постоянные проблемы с туманными багами в разных конфигурациях серверов.

Так вот: "я же говорил!!!" Примерно вчера за тикет взялся один человек — Майк Аксияк — который начал с того, что обсудил в django-developers дизайн, ничем не связанный с предыдущим, а сегодня уже сделал работающие патчи. Майк мой герой!

Кстати, сам дизайн — сказочный. Джанго не просто будет сваливать большие файлы на диск. Нет, это она будет делать по умолчанию. Но вместе с этим у юзера появится отдельный хук: request.set_upload_handler(<handler>), в который можно будет передать свой собственный хэндлер и делать там много интересных вещей. В частности в обсуждении родились идеи:

А теперь — все идем тестировать патч!

Комментарии: 12

  1. Boo

    отличная новость! :)
    спасибо.

  2. Банзай

    Это очень хорошая новость. Но я так до конца и не понял, в чем собственно эта новость заключается :) То есть, тикет с патчем уже был давно и все ждали, когда же его примут в основную ветку. Теперь получается, что появился новый, более продуманный патч? Если так, то когда же его наконец заапрувят?

  3. igorekk

    Замечательно :) Надо будет потестировать. Сейчас как раз проект делаю с возможностью аплоада файлов.

  4. elephantum

    совершенно неконсистентно с остальным дизайном джанги. хотя его уже сложно испортить, всеравно =)

  5. Иван Сагалаев

    Немножко неконсистентно, да... Возможно, через полгодика оно переедет на что-то вроде

    UPLOAD_HANDERS = [
    django_progresbar.handler,
    user_quota.handler,
]

    Но с другой стороны, эта штука скорее per-view, чем per-project, поэтому так тоже не очень удобно.

  6. Муркт

    На седьмом Эксепшене, во время своего рассказа про Django, Дейв упомянул про этот тикет, добавив что-то вроде: «Не назову сейчас его номер». Когда я громко сказал: «2070!», в зале раздался смех :)

  7. Иван Сагалаев

    Что интересно, ровно такой же момент был и на шестом Exception'е тоже :-)

    Вот тут на w2.com.ua есть видео, там в районе времени 1:00:08 я номер патча произношу с той же реакцией аудитории :-).

  8. elephantum

    Вообще эта штука per-file-select-field то есть в идеале это должен быть аттрибут у поля формы, который генерирует такой JS, который вызывает нужный питоний хендлер.

  9. Иван Сагалаев

    Не, это фигня будет.

    Во-первых, не очень понятно зачем тут JS, и даже если он и нужен, то это очень плохо, потому что в интернете много user agent'ов, которые JS не понимают. Что будет происходить, если они будут такие формы аплоудить?

    Во-вторых, почти никогда одно поле формы не имеет семантики без контекста формы. Фактически этот контекст — "поле с файлом в форме такой-то" — заменяет тот гипотетический JS, который ты предлагаешь для сообщения полю семантики. А следовательно это таки per-view функциональность, потому что обработкой формы занимается одна view.

    Говоря по-другому, Django все таки REST-ориентированная система, поэтому клиентская часть не должна срастаться с серверной по-контролно, как во многих не-MVC GUI-системах кнопочки в окне самостоятельно провязаны с моделью данных. То есть, Django — это не GWT, где твое предложение имело бы смысл.

    P.S. Никто еще не заснул? :-)

  10. Mike Axiak

    I wish I could understand this! Anyway, I'm still working on it...today there should be a much better patch. (Though the original design is the same.)

    To address your per-view complaint: Maybe I'll breakdown and put some fallback in settings...the problem is that I want instances, not classes, so that you can put arbitrary information in them (like the current request). We could also write a middleware like django.middleware.upload_handlers that will set the upload handlers by calling Class(request).

    Anyway, any feedback is appreciated!

  11. Иван Сагалаев

    Thanks for joining in, Mike!

    I wasn't actually complaining about per-view nature of this thing. Actually we need both: a global "setting" for things like per-user quotas and per-view behavior for things that depend on a form being uploaded. Currently in Django this is solved with middleware and decorators respectively. So I actually think your current design may remain intact as a low-level API. And for user-level API we could recommend in docs to implement actual functionality as decorators and middleware.

    I actually have some further thoughts but I'll post them in django-developers. If they become clear enough to articulate, that is :-)

  12. Boo

    Закоммитили!
    http://code.djangoproject.com/changeset/7814

Добавить комментарий