Опубликован черновой вариант книги о Pylons

>встраивать блоки кода прямо внутрь тега.

"Для Вас, Козлов, темплейты придумали"

Pylons не нужно, grails - наше всё!

блин ну хотя б заголовки новостей можно оформлять по нейтральней: а то черновой, книги - жусть брр..

Статья о Pylons, а тег присвоен py[t]lons... Поправьте.

> Почему-то всегда, когда вижу много кода, перемешанного с тэгами, хочется ударить автора кода по голове, или даже плюнуть в глаза.

Вот-вот, или: ударить в глаз! :)

> sqlalchemy - must die.

Признайся, просто ниасилил :)

> Гораздо лучше писать sql запросы прямым текстом.

Бугога. Ты, похоже, вообще не шаришь в идее объектно-реляционной проекции.

Алхимия - лучшее из того, что сейчас есть из пайтоновских ORM. Возможности просто безграничны, до голого SQL опускаться вообще не нужно никогда (превед, Django ORM), миграция на другие СУБД - в два тычка по клавиатуре. Насчет тормознутости - ищи проблемы в своем коде, ога. Или ты уже написал нечто столь же полезное и масштабное, как sqlalchemy?

c: "teating"

Зачем оно нужно, если есть

LAMP + Eclipse PDT + PHP for Applications based on Zend Framework

Зачем это, если мы итак все умрем

>Алхимия - лучшее из того, что сейчас есть из пайтоновских ORM. Возможности просто безграничны, до голого SQL опускаться вообще не нужно никогда (превед, Django ORM), миграция на другие СУБД - в два тычка по клавиатуре.

И кофе сама варит :)

>Насчет тормознутости - ищи проблемы в своем коде, ога

делал тест: выборку в цикле. Обычный dbapi — 3000 запросов в секунду, выбор через sqlalchemy без ORM — 30 запросов, с ORM — 20.

Проблему в своём коде нашёл, конечно: использование SQLAlchemy. Нах-нах такое счастье :)

Если, конечно, программа GUI'шная, и выполняется в ней по запросу в секунду, то всё тип-топ. Но на нагруженном веб-приложении таким тормозным монстрам не место.

> лучшее из того, что сейчас есть из пайтоновских ORM. Возможности просто безграничны, до голого SQL опускаться вообще не нужно никогда

Если честно, никогда не понимал глубокого смысла ОРМ. Тот же SQL только боком выходит. Только на желаемом ЯП. Это что, чтоб SQL не учить? Работал одно время с SQL Object, совершенно выигрыша в скорости написания кода не ощутил. И читать SQL как-то понятней. ИМХО

>>Гораздо лучше писать sql запросы прямым текстом.

>Вы это, помягче пишите, а то страшно становится иногда.

Мягкий человек, вы нагруженные Web проекты писали?

Нет, кофе варить не умеет, и в грабеже корованов не сильно помогает :)

> делал тест: выборку в цикле. Обычный dbapi — 3000 запросов в секунду, выбор через sqlalchemy без ORM — 30 запросов, с ORM — 20.

Что-то с трудом верится. Прийду домой - сам попробую.

> Проблему в своём коде нашёл, конечно: использование SQLAlchemy. Нах-нах такое счастье :)

И что же, сырой SQL? А в целом проект на ассемблере писан? ;)

> Но на нагруженном веб-приложении таким тормозным монстрам не место.

Ничуть не монстр и не разу не тормозной. Не всем суждено понять реальные pros и cons.

Эх... Прошли те времена, когда каждый пытался написать свою графическую библиотеку: теперь прогер - не прогер, если не напишет свой web content manager! Причём независимо от квалификации и степени освоения остальных CMS.

Ещё прикольно читать во введении к очередному велосипеду: "Вобрал в себя лучшее из blah-blah...". Ну вобрал. А выдыхать кто будет? :)
Скопировать несколько фичей - ума много не надо, а сделать продукт ДЛЯ ЛЮДЕЙ - вот это настоящая работа!

> Если честно, никогда не понимал глубокого смысла ОРМ. Тот же SQL только боком выходит. Только на желаемом ЯП. Это что, чтоб SQL не учить? Работал одно время с SQL Object, совершенно выигрыша в скорости написания кода не ощутил. И читать SQL как-то понятней. ИМХО
Может, стоит попробовать?

1. Не болит голова об эскейпировании данных вообще - никакие инъекции не страшны в принципе.
2. Нет идеологического "семантического разрыва" в разработке - в "олд-скул стайл" со стороны приложения оперируешь объектами, а для перзистентного сохранения приходится оперировать строками таблиц <- не удобно и не практично.
3. Скорость разработки действительно возрастает в разы - для элементарных операций не нужно писать мутные запросы.
4. Миграция на любую СУБД легко и просто.

И еще:
1. От необходимости знания SQL не освобождает.
2. SQLObject гадость.
3. Читать код, написаный с исп. нормального ORM намного понятней.

obj = Person.objects.get(id=666)
obj.name = 'сцотона'
obj.save()

Имхо, намного понятней и красивее, чем полэкрана кода с SQL-запросами.

C ORM возня какая-то непонятная возникает в рамках веб приложения. Надо всякие scoped сессии неочивидные выстраивать, что б разные пользователи в своих песочницах варились и не обновляли поля объектов друг у друга

>1. Не болит голова об эскейпировании данных вообще - никакие инъекции не страшны в принципе.

Связанные переменные для кого придумывали? Вы python dbapi о старым php mysql не попутали?

>2. Нет идеологического "семантического разрыва" в разработке - в "олд-скул стайл" со стороны приложения оперируешь объектами, а для перзистентного сохранения приходится оперировать строками таблиц <- не удобно и не практично.

А потом догадываться, какой запрос слепил этот ORM, когда база прогибаться начинает, и начинаешь её оптимизировать

>3. Скорость разработки действительно возрастает в разы - для элементарных операций не нужно писать мутные запросы.

Оттуда же. Закон дырявых абстракций тут виден в полный рост. ORM сделала запрос, для которого оптимизатор в базе не нашёл индекс, в итоге проект стоит раком от 10 транзакций в секунду.

>4. Миграция на любую СУБД легко и просто.

Опять же, только на словах. Когда заточишь запросы под одну СУБД, на второй они работать будут, но наприседаешься с ними… Если, конечно, базу юзаешь не как DBF, что подмывает делать через некоторое время

>obj = Person.objects.get(id=666)

>obj.name = 'сцотона'

>obj.save()

cursor.execute('UPDATE person SET name=? WHERE id=?', ('сцотона' , 666))

Даже понятнее, имхо

> Может, стоит попробовать?

Дык пробовал.

> 1. Не болит голова об эскейпировании данных вообще - никакие инъекции не страшны в принципе.

Так апи не принуждает делать инъекции. Если использовать "?" то проблем я не припомню.

> для перзистентного сохранения приходится оперировать строками таблиц

Зачем данные из запроса хранить персистентно?

> 4. Миграция на любую СУБД легко и просто.

Легко и просто только для дико простых вещей. Оракел и дбф никакая ОРМ не сравняет. Что, прикажешь делать со всеи этими триггерами, хранимыми процедурами, особенностями синтаксиса и прочими возможностями, уникальные для каждой СУБД?

> 3. Скорость разработки действительно возрастает в разы - для элементарных операций не нужно писать мутные запросы. obj = Person.objects.get(id=666) obj.name = 'сцотона' obj.save()

1) Вот тут у тебя дико простая ситуация. А если заполняться должно 2 десятка полей да по хитрому условию? Проблема не сколько в запросах модификации, сколько в выборках. 2) На самом деле большой проблемы в том, что напишу пару лишних слов я набью не вижу - основные временные затраты не набор текста. Причем далеко не всегда ОРМ код будет короче и читабельней. 3) никакие запросы не мутные, как раз наиболее четко описывается предметная область 4) В данном случае у тебя будет 2 строчки на питоне. Никак не полэкрана.

> cursor.execute('UPDATE person SET name=? WHERE id=?', ('сцотона' , 666))

Забыл коммитнуть. Хотя это от СУБД зависит

Чел выше даже запрос не отправил :) там ещё session.flush() надо сделать. Оно крепко задумается, сделает топологическую сортировку, соберёт каждый запрос через бакенд, и много чего ещё намутит. Причём это надо иметь в виду, иначе будут сюрпризы.

А коммит обычно делается после отработки HTTP запросов, перед тем, как в шаблон данные кормить

> cursor.execute('UPDATE person SET name=? WHERE id=?', ('сцотона' , 666))

Ну допустим, а если нужна связь многие-ко-многим? И как выборку в старом стиле (строку таблицы + строки связанных таблиц) преобразовать в экземпляры классов?

От пси-шторма гидры Лопнут как гондоны! Быстро развивайся, Чаще строй пилоны.

От пси-шторма гидры

Лопнут как гондоны!

Быстро развивайся,

Чаще строй пилоны.

>Ну допустим, а если нужна связь многие-ко-многим? И как выборку в >старом стиле (строку таблицы + строки связанных таблиц) преобразовать в экземпляры классов?

Слова масштабируемость и нормализация это антонимы.

Зачем их преобразовывать. СУБД сами должны сделать необходимые изменения в связанных таблицах. Это если я правильно понял вопрос.

> Вообще, я понял. На тут джанга - это сложная тема. Сразу найдутся противники, жабафанаты, пыхофанаты... Как две разные крайности. А ведь джанга хорошая! Получше некоторых. А эти пилоны - надо почитать, вдруг крута. Алхимия не понравилася, сложнее по сравнению с джанговскими ORM

При отравлении мозгов SQLAlchemy рекомендовано пить Elixir (http://elixir.ematia.de/trac/wiki) :-)

> Монструозная не монструозная, а только ты о чём-то задумываешься - а оно в джанге есть! может я думаю примитивно...

Скорее в стиле django, раз не возникали вопросы с наследованием бизнеc-объектов.

> делал тест: выборку в цикле. Обычный dbapi — 3000 запросов в секунду, выбор через sqlalchemy без ORM — 30 запросов, с ORM — 20.

Мил человек, а ты поля из recordset читал или так, просто запросы делал? Потому как падение в 100 раз ни одним ORM оправдать не получится.

>Ну допустим, а если нужна связь многие-ко-многим? И как выборку в старом стиле (строку таблицы + строки связанных таблиц) преобразовать в экземпляры классов?

не надо ничего преобразовывать. Используй прямо кортежи. На вебе чем «деревяннее», тем надёжнее. Сам запрос просто необходимо писать руками, иначе потом заколебёшься искать его, когда придётся оптимизировать. И объяснять ORM'у, что надо поменять местами таблицы в join'е, потому что производительность будет в разы отличаться от простой перемены порядка их следования.

Потом будешь объяснять ORM'у, в каком порядке запросы на параллельных нитях исполнять, чтобы deadlock'ов не было. Оно их топологически отсортирует, и для конкретной нити порядок будет правильный. А под нагрузкой приложение будет ловить deadlock'и.

>Мил человек, а ты поля из recordset читал или так, просто запросы делал?
>Потому как падение в 100 раз ни одним ORM оправдать не получится.

connection.begin()
cursor.execute()
connection.commit()

и

session.begin()
obj = Sample.get(1)
session.remove()

Профилёр показывает, что оно залипает на флаше сессии.

Просто голый проект на pylons сделай, будет порядка 1000 запросов в
секунду делать. Потом в base.py добавь создание сессии перед вызовом
контроллера, и remove после. Зацени падение скорости (до 200
примерно). Потом сделай выборку объекта. Замедлится до 100. Сделай
выборку связанных объектов. Упадёт до 50. Сохрани что-нибудь.
Получишь 25-30.

Помнится ОРМ была (и есть) в Делфи. TTable с нащадками. Народ подкупался первоначальной простотой, но как только дело доходило до сколько-нибудь высокого уровня абстракции - все, абзац (хотя в Делфи с любым, сколько-нибудь серьезным уровнем абстракциии абзац, ИМХО). Сразу переходили на SQL. Тут ситуация похуже - Алхимия и т.д. помощнее, факт. Но все теже грабли присутствуют и тут. Только если там народ сваливал сразу, потому, что гавно явное, то тут оно ни туда, ни сюда. Кстати с дбф там скорость работы приличной была, а когда тоже соорудили для нормальных СУБД все, тормоз на тормозе. Вот и результат переносимости - ни скорости ни функциональности.

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

Да его и написать не вопрос заново, если не веришь, сам попробуй. Только кеширования всяческие выключай (точнее, сессию remove надо делать в обязательном порядке, иначе в многонитевом приложении настанет задница)

> cursor.execute('UPDATE person SET name=? WHERE id=?', ('сцотона' , 666)) > Даже понятнее, имхо а теперь тоже самое, но с контролем LENGTH(NAME) > 0 и в трех местах :-)

>а теперь тоже самое, но с контролем LENGTH(NAME) > 0 и в трех местах :-)

один constraint в базе

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

>session.begin()
>obj = Sample.get(1)
>session.remove()

Поправь меня если я не прав, но разве remove не делает rollback транзакции? По идее должно бы быть

session = Session()
obj = Sample.get(1)
session.commit()

только наверное не стоит get(1) писать, а то еще закэширует

>> а теперь тоже самое, но с контролем LENGTH(NAME) > 0 и в трех местах :-)

> один constraint в базе

чудно, а теперь внятно объясни пользователю, что произошло не нарущение C12456889, а он неправильно ввел имя

> Предлагаю открыть для себя хранимые процедуры, триггеры, ключи, всевозможные проверки, права доступа и т.д. И все на уровне СУБД. Все это уже много лет как придумано до нас.

Предлагаю открыть для себя мир прикладного программного обеспечения, где белая страница "500 Внутренняя ошибка сервера" не котируется.

>Если честно, никогда не понимал глубокого смысла ОРМ. Тот же SQL только боком выходит. Только на желаемом ЯП. Это что, чтоб SQL не учить?

ORM предоставляет кучу предлестей "из коробки" - например реализует Unit of Work, identity кэши, оптимистические и пессимистические блокировки, многоуровневое кэширование (возможно даже кластерные кэши) - все это для более или менее сложного приложения придется реализовывать все равно в том или ином объеме. А SQL учить все равно придется.

И каким боком ошибка 500 к встроенным возможностям СУБД?

>1. Не болит голова об эскейпировании данных вообще - никакие
инъекции не страшны в принципе.

используйте препарированные запросы.

>2. Нет идеологического "семантического разрыва" в разработке - в
олд-скул стайл" со стороны приложения оперируешь объектами, а для
перзистентного сохранения приходится оперировать строками таблиц <-
не удобно и не практично.

используйте DAO и буде вам счастье.

>3. Скорость разработки действительно возрастает в разы - для
элементарных операций не нужно писать мутные запросы.

для элементарных операций - запросы элементарны.

>4. Миграция на любую СУБД легко и просто.

используйте ANSI SQL и выносите запросы из тела приложения в
конфигурационный файл.

для серьезных приложений наличие явно SQL в конфигах дает возможность
для DBA (или тем, кто занимается потдержкой) тюнить ваши запросы в
любой момент времени. Таким путем идет например жабский iBatis.

в Grails это делается локализацией одной строчки.

>Поправь меня если я не прав, но разве remove не делает rollback транзакции?

щас не вспомню. Вроде бы, если стоит флаг автокоммит, оно перед удалением закоммитит. С точки зрения базы в тесте всё было правильно. Срисовано с их примеров

> И каким боком ошибка 500 к встроенным возможностям СУБД?

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

>чудно, а теперь внятно объясни пользователю, что произошло не нарущение C12456889, а он неправильно ввел имя

валидацию должен делать контроллер. Ты про MVC хорошо читал? Задача constraint'а только в том, чтобы у тебя не развалилась database consistency

>в Grails это делается локализацией одной строчки.

в алхимии в любом случае придётся ловить исключение и протаскивать перевод через пилонсовскую i18n.

И ещё раз: проверку вводимых данных должен проводить контроллер. Чтобы иметь возможность перегенерить форму, пометив неправильно введённые данные.

Большинство современных СУБД генерируют исключения, если что не так.

>Спрашивается зачем мне возможности СУБД, если я все это могу на уровне бизнес-объектов описать, которые потом зачастую сами СУБД настроят.

чтобы твоё чудо-приложение не легло под нагрузкой. Я могу поверить, что какой-нибудь hibernate или iBatis сделает объектный доступ быстрым и красивым, но SQLAlchemy делает доступ красивым, но неимоверно медленным. По этой причине на нагруженных сайтах использоваться не может. К тому же, нормального пути тюнить запросы у неё нет.

И ты можешь эти исключения сам определять.

>Помнится ОРМ была (и есть) в Делфи. TTable с нащадками.

вам нужно почитать про ORM ...

ЛОР как всегда уныл, уже и ORM обговняли. А мне джанговский нравится например, удобно, я считаю, правда не всё через него реализуемо, иногда юзаю SQL.