На этих выходных в Django была включена поддержка Oracle.

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

А вот еще маленький показательный пример Правильной Вещи™.

Недавно в trunk'е переделали вывод результат работы шаблонов: раньше весь результат формировался в одну большую строку в памяти и выдавался сразу, а его переделали на покусочную выдачу блоков по мере готовности. Теоретически это должно было дать прирост производительности из-за убирания пары мест, где строка копировалась в памяти. Однако это вылезло небольшими изменениями семантики окончания запроса, из-за чего коннекты к базе закрывались раньше выдачи шаблона, потом открывались в нем заново и висели вечно. А также непредвиденными потерями в производительности, из-за отсутствия буферизации вывода.

Так вот вместо того, чтобы быстро-быстро все латать, эти изменения просто отменили, чтобы разобраться с ними спокойно, и чтобы они не мешали основному течению задач.

Хорошо :-).

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

  1. Denya

    Не в тему, но.
    В RSS когда отдаешь неполную запись, указывай это пожалуйста :)

    А то не понятно, есть ли что там "читать дальше" или нету.

  2. igorekk

    Отличная новость. Особенно в вероятности выкатывания юникодной ветки.

  3. koder

    Поддержка Oracle сомнительное достоинство,IMHO.
    Стоит Oracle дофига, требует соотв. железа для
    получения результата, большая часть людей, занятых
    в web никогда с ним не работала , укорить он
    врядли что-нить сможет, т.к. django по большей
    части будет "слабым звеном" да и даже весьма
    нагруженные сайты неплохо себя чувствуют на
    MySQL/PostgreSQL. Разве-что "Proof of concept" -
    так разве кто сомневался что можно?

  4. Alexander Solovyov

    Поддержка Oracle сомнительное достоинство,IMHO.

    Сомнительное - это когда сомневаешься, достоинство или недостаток. :) Поддержка Оракла - несомненное достоинство. :)

  5. koder

    Ок, практическая польза от поддержки Oracle,
    IMHO, меньше предела измерения ;).

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

    Но почему? Есть люди, у которых уже стоит Оракл (прочно и надолго). Почему бы не дать им возможность использовать Django? Чем это может быть плохо?

  7. 3BEP

    Тру Оракл админ умрет или убьет увидев сгенерированную схему базы. Все-таки разница между SQLite и Ораклом есть. Тем, кто такой разницы не видит - вполне подойдет SQLite. Зато не будет неоправданных надежд в плане производительности.

  8. dobrych

    Не могу спорить по поводу разных SQL DB/Engines.
    Могу сказать одно, в рассылке достаточно часто спрашивали про поддержку Oracle (насколько мне помнится как раз люди у которых уже есть Oracle в продакшене), именно поэтому и сделали, что востребованно оно. А если сделали то, что востребованно - значит преимущество!

  9. koder

    Но почему? Есть люди, у которых уже стоит Оракл
    (прочно и надолго). Почему бы не дать им
    возможность использовать Django? Чем это может
    быть плохо?

    В этом нет ничего плохого. Но таких людей так
    мало что ради них добавлять в джанго вагончик
    кода IMHO не стоило. Дальше - если у человека
    стоит Oracle то явно для чего-то серьезного и
    нагружать тот-же сервер django'й станет вовсе не
    каждый.
    И, наконец, три - он всегда может поставить себе
    еще mysql, прикрутить в ней размер кеша, приоритет
    и получить свой сайт. В качестве примера - даже самые загруженные PHP сервера замечательно
    обходятся без "тяжелой артилерии" типа Oracle,
    и я не верю что связка Oracle/Django будет
    использоваться.

    P.S. Тут недавно кое-кто говорил что history
    к постам в форуме - излишество. Это излишество
    куда больше.

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

    В этом нет ничего плохого. Но таких людей так мало что ради них добавлять в джанго вагончик кода IMHO не стоило.

    Хм... Тут, похоже, есть недопонимание того, как это все работает. Это не для кого-то джанговские девелоперы взяли и написали поддержку Оракла. Это сами люди, которым она была нужна, собрались, написали, поддерживали бранч 8 (кажется) месяцев и собираются поддерживать дальше уже в основной ветке. То есть их оказалось достаточно много, чтобы довести дело до конца.

    Дальше - если у человека стоит Oracle то явно для чего-то серьезного и нагружать тот-же сервер django’й станет вовсе не каждый.

    А тут недопониманий я вижу, уж простите, два :-).

    Во-первых, нет никакой нужды нагружать Django'й тот же сервер, она прекрасно будет работать и на соседнем.

    Но это мелочь. Главное, что меня всегда искренне удивляет — это вот это деление на "серьезность" и "несерьезность". Приведите, пожалуйста, пример такой веб-задачи, которая бы ясно показывала, что это вообще означает?

    В качестве примера - даже самые загруженные PHP сервера замечательно обходятся без “тяжелой артилерии” типа Oracle

    Повторюсь, это актуально не тем, кто начинает писать новое веб-решение и может обойтись. А тем, у кого уже есть база под Ораклом, и к ней надо сделать веб. База с живыми данными обычно является хребтом всей организации, поэтому перевести ее со всей логикой на любую другую обычно просто абсолютно нереально. И уж точно не по причине того, что Оракл — это "слишком серьезно".

    и я не верю что связка Oracle/Django будет
    использоваться.

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

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

    Тру Оракл админ умрет или убьет увидев сгенерированную схему базы.

    Почему? Django не навязывает четкой схемы, достаточно, чтобы совпадали названия таблиц, полей и их типы, и все. DBA волен делать все что угодно с индексами, tablespace'ами, вьюхами и процедурами. Собственно, Джанго и генерировать схему не заставляет, просто это в большинстве случаев и удобно, и подходит.

  12. koder

    Во-первых, нет никакой нужды нагружать
    Django’й тот же сервер, она прекрасно будет
    работать и на соседнем.

    Отжирая мощьности и память того самого не
    соседнего. Одна малина.

    Это сами люди, которым она была нужна,
    собрались, написали, поддерживали бранч 8
    (кажется)

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

    Есть люди, у которых уже стоит Оракл (прочно
    и надолго).

    Приведите, пожалуйста, пример такой
    веб-задачи, которая бы ясно показывала, что
    это вообще означает?

    Oracle как раз не ради веба ставят, а для BL какой-нить тяжелой софтины.
    Я конечно ничего действительно тяжелого web не
    видел, но, например, новостной сайт, под который
    писался Django явно ходит не под Oracle(иначе
    поддержка Oracle в Django была-бы изначально). А
    это довольно нагруженный ресурс.

  13. koder

    Отжирая мощьности и память того самого не
    соседнего. Одна малина.

    Бред написал - если ставить для Django отдельный
    Oracle сервер(в смысле отдельную машину), то
    нужно нормально денег выкинуть(Oracle + соотв.
    тачка).

    И предпоследний абзац - тоже цитата.

  14. Горбунов Олег

    Уважаемый, вы говорите о вещах, которые сами не пробовали. У нас в компании, например, много веб-приложений внутреннего использования, с базой Oracle работающих — и по моим впечатлениям Oracle востребован, и вполне стоит своих денег.

  15. Seroga

    Хм. А у нас архитектура именно такая: сервер СУБД (Oracle, кстати) + веб-сервер на разных машинах физически. И это оправдано как минимум из соображений безопасности и производительности.

    Oracle востребован, и вполне стоит своих денег.

    Согласен на все 100%

  16. Seroga

    Приведите, пожалуйста, пример такой веб-задачи, которая бы ясно показывала, что это вообще означает?

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

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

    Нет, я имел в виду в рамках вот этой цитаты:

    Дальше - если у человека стоит Oracle то явно для чего-то серьезного и нагружать тот-же сервер django’й станет вовсе не каждый.

    Я попросил пример того, что система с Ораклом + Джанго является менее "серьезной" чем просто с Ораклом. Я просто вообще не понял, о чем речь.

  18. koder

    Я попросил пример того, что система с Ораклом
    + Джанго является менее “серьезной” чем просто
    c Ораклом. Я просто вообще не понял, о чем
    речь.

    А так-же Serog'е и Горбунову Олегу.

    Ради чего ставят Oracle?

    1)Производительность при больших нагрузках.

    Для того что-бы нагрузить Oracle из Django
    прийдется запустить действительно МНОГО Django
    серверов, я думаю порядка сотни.

    2)Обширные возможности PL/SQL и все остальные
    расширения.

    Полностью идут лесом из-за ORM(что,
    то-же, кстати, не позволит достичь высокой производительности. Т.к. никакого "тюнинга"
    запросов Вы сделать не сможете). Именно
    это и имелось в виду под "серьезностью" - с
    позиции Django Oracle не отличается от SQLite.
    И используется ровно так-же как SQLite - забивание гвоздей микроскопом с очень удобной ручкой. Для сравнения оракловские
    проэкты, которые я видел, вмещали более 1000
    тяжелых процедур, т.е. там "жило" процентов 40
    бизнес-логики и все отчеты. Я уже молчу про
    пользовательские типы данных, вьюхи,etc.
    Кстати - именно высокая скорость обработки
    данных встроенными процедурами и есть основная
    сильная сторона Oracle. На plain request его
    превосходство(над MySQL или PostgreSQL, в
    зависимости от задачи) гораздо меньше.

    3)Удобство администрирования, профилирования,
    etc.

    Из-за того-же ORM большая часть этих удобств будет не нужна/(не принесет пользы). Хотя это
    IMHO основная(и единственная серьезная) причина использовать здесь Oracle.

    Oracle востребован, и вполне стоит своих
    денег.

    А я что говорил обратное? Просто при
    использовании вместе с Django Вы заплатите
    больше половины денег за то что использовать не
    будете.

    Надежность и безопасность гораздо выше, когда
    на каждом сервере стоит своя база, а не все
    работают на одном.

    Причины использовать Oracle c Django могут
    быть(существующая Web инфраструктура, например),
    но до сих пор все кто Django использовал,
    а это и весьма крупные новостные агентства,
    с серьезной нагрузкой, как-то жили без Oracle
    (это я повторяюсь, т.к. прошлый пост, кажется,
    никто не читал) => он им был не нужен, иначе уже
    бы давно прикрутили.

  19. crash

    Знаменательное событие, теперь, после слияния ветки Oracle джанговцы наконец-то сольют и UnicodeBranch :)

  20. peroksid

    Люди написали себе, сами используют, всем хорошо. Чего вы кипятитесь? Код этот никому на мозги не действует, в него никто кроме тех, кому это надо, заглядывать не будет. Так разве плохо?

  21. dem

    Вопервых Django не требует везде использовать встроенный ORM. Во вторых выход поддержки оракла хорош даже для тех у кого этого самого оракла нет.
    почему? Да потомучто подтвердит что встроенный ОРМ умеет еще один диалект SQL, появится еще один вагончик кода который можно подсмотреть прикручивая ОРМ к другой БД (у меня например Advantage - там очень похож SQL). Никто специально Оракл использовать только для web задач не собирался (это вам уже и до меня сказали). Например у меня в БД организации уже есть система авторизации. Мне надо выкладывать некоторые данные в WEB. Данные я беру из Адвантажа, а вот пользователей пришлось завести своих в SQLite потомучто Джанга его не знает, а встроенная админка и система прав удобна.... Вот вам и пример. А скепсис ваш просто из-за того что вы боитесь что поект разжиреет....

  22. koder

    to Dem.
    Хорошо, давайте, применив Ваши аргументы,
    прикрутим к джанго ВСЕ остальные базы данных.
    Т.е. в вашем посте меняем Oracle, например, на
    DB2(Адвантаж) и вперед? Вся аргументация
    остается в силе.

    ..еще один вагончик кода который можно
    подсмотреть прикручивая ОРМ к другой БД....

    IMHO 4-х баз более чем достаточно для
    подсматривания.

    Никто специально Оракл использовать только для
    web задач не собирался (это вам уже и до меня
    сказали)

    Вы, как и почти все остальные, усиленно читаете мои посты до половины.

  23. Boo

    Дождались. Unicode-branch слился с trunk

  24. dem

    2koder Насчет БД - да аргументация в силе. Оракл замечателен тем, что по возможностям больше него ничего нет. Насколько я помню Python модуль для оракла (DB API), нечто большее чем требует DB API. Следовательно и в Django бэкэнде для Оракла можно расходится по самое не хочу.
    Насчет чтения постов на половину: видимо просто не получилось у вас донести основную мысль. Я подозреваю, что она заключается в том, что Django это не тот инструмент который выжмет все возможности Оракл... Ну так и не надо. Есть средство лучше чтоб данные из БД в WEB класть?

  25. lyx

    Прочитала тут много, судя по постам многие просто не работали с ораклом, или работали так, в ознакомительном порядке.
    У меня есть достаточно большой опыт миграции сайтов с oracle на mysql.
    Восновном оракл показывает себя лучше в сложных заросах где используется 3 и более таблиц, сайты же например на дьянго кишат плоскими запросами.
    Плюс оракл очень плохо выдерживает огромные потоки( 1 соединение жрет много системных ресурсов намного больше чем в mysql), запросов ему бы поменьше но по сложней, такой результат показал почти во всех режимах оракла которые мы в нем нашли и рекомендовал нам саппорт.
    Поэтому лично мое мнение не стоит использовать дьянго совместно с ораклом если это не сложная вычислитебльная система с кучай фоновых задач и максимум 300 пользователей онлайна.

  26. ph

    Хочется поддержу DB2... Самому делать времени нет совсем:(

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