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

>Я могу поверить, что какой-нибудь hibernate или iBatis

гемора хватает и в hibernate с iBatis попроще, да сам он проще.

Это разве не примитивный ОРМ?

вот я и говорю - pylons ну нужно, используйте Grails:

http://grails.org/doc/1.0.x/guide/single.html#7.4 Validation and Internationalization

user.login.blank=Your login name must be specified!

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

Вроде как в их примерах нет autocommit, есть только autoflush. Ремомендованный ими подход для web предусматривает commit (http://www.sqlalchemy.org/docs/04/session.html#unitofwork_contextual_lifespan)

Да и писать инициализацию БД в base.py несколько странно, в то время как pylons рекомендует это в environment.py

Хотя весь мой опыт общения с ОРМ - питоновские ОРМ, которые, на момент моего с ними знакомства управлять кешами и т.д. не умели. С другой стороны я понимаю, что не совсем прав, но в топике идет обсуждение использования ОРМ, как того TTable.

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

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

В том и суть, что контроллер не единственный. Вобщем читай пост про изменения в трех местах :-)

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

>Да и писать инициализацию БД в base.py несколько странно

не БД, а сессии.

>Вроде как в их примерах нет autocommit

пардон, подзабыл. Вообще, вроде как-то так:

try:
   #call controller
   session.commit()
except:
   session.rollback()
   raise
finally:
   session.remove()


Но это не принципиально. Работало оно правильно, но нереально
медленно. Замедление даже в 3 раза — это уже нонсенс. 
А на порядки — катастрофа

CREATE EXCEPTION YOUR_EXCEPTION 'Your readable text' СУБД Firebird вернет ошибку YOUR_EXCEPTION с текстом 'Your readable text'

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

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

мне бы в hibernate его проблемы с тюнингом запросов :-)

>В том и суть, что контроллер не единственный. Вобщем читай пост про изменения в трех местах :-)

Ммать... Оптимизаторы, блин. Прочитай, что я говорил о показе этих долюанных ошибок ввода. То, чем ты занимаешься, называется «поиск мозга в жопе». То, как обрабатывать некорректно введённые данные, может сказать только контроллер. И catch'ами ловить исключения при присваивании — это верх идиотизма. Даже в пилонах есть модуль для валидации ввода, с кучей бредового кода. Намного проще аккуратно прописать валидацию в методе контроллера

> CREATE EXCEPTION YOUR_EXCEPTION 'Your readable text' СУБД Firebird вернет ошибку YOUR_EXCEPTION с текстом 'Your readable text'

круто! а где еще работает? а как текст на разных языках сделать? а как сделать, чтобы срабатывала на INSERT без необходимости писать сохраненные процедуры и триггеры?

>Хотя весь мой опыт общения с ОРМ - питоновские ОРМ, которые, на момент моего с ними знакомства управлять кешами и т.д. не умели. С другой стороны я понимаю, что не совсем прав, но в топике идет обсуждение использования ОРМ, как того TTable.

как вы знаете, ORM сериализация бизнес модели (бизнес объектов) в реляционную базу. TTable - это отображение таблицы (или view) реляционной базы в объект класса TTable, причем 1 в 1. По сути это даже нельзя назвать кастрированным фаулеровский Active Record.

> Но это не принципиально. Работало оно правильно, но нереально медленно. Замедление даже в 3 раза — это уже нонсенс. А на порядки — катастрофа

да в том и дело, что 3-10 раз терпимо, а 100 совершенно ничем не объясняется

> Ммать... Оптимизаторы, блин. Прочитай, что я говорил о показе этих долюанных ошибок ввода. То, чем ты занимаешься, называется «поиск мозга в жопе». То, как обрабатывать некорректно введённые данные, может сказать только контроллер. И catch'ами ловить исключения при присваивании — это верх идиотизма. Даже в пилонах есть модуль для валидации ввода, с кучей бредового кода.
лично я не в восторге от валидации на уровне форм

>Намного проще аккуратно прописать валидацию в методе контроллера
проще писать в стиле ActiveRecord, когда модель делает свою валидацию и ловить одно единственное ValidationError cо всеми ошибками

А правильно пусть делают те кому время некуда девать...

> а где еще работает?

В постгрессе, например. Только там синтаксис другой.

> а как текст на разных языках сделать?

Например ч-з gettext - ты же сумел идентифицировать исключение.

> а как сделать, чтобы срабатывала на INSERT без необходимости писать сохраненные процедуры и триггеры?

1) А чем так страшны триггеры и процедуры? 2) может зависеть от СУБД

>да в том и дело, что 3-10 раз терпимо, а 100 совершенно ничем не объясняется

бакенд _каждый раз_ строит SQL запрос. Как только ты делаешь session.query(Sample).blah, оно строит запрос. Как только ты делаешь session.flush, оно выполняет сортировку и заново создаёт запросы. Причём кеширование, я так понимаю, сделать очень сложно, поэтому о подготовленных запросах можно забыть.

В инете находил сравнение алхимии и некоторых других систем. Алхимия тормозит примерно так же, как и в моём случае. Майк показывал, как заточить её до уровня остальных, чтобы было в 3 раза медленнее, чем натив, но все её достоинства при этом теряются.

Почитал я этот тред и решил посмотреть в сторону написания SQL-запросов вручную. Есть ли какие-нибудь средства для преобразования результатов в экземпляры классов? На что стоит посмотреть?

К полям кортежа можно обращаться по имени. У постгреса, во всяком случае. Зачем тебе в питоне поля класса, вообще?

Чтобы можно было, например, передать в шаблон экземпляр класса и
вызывать какие-нибудь его методы. Пример из одного моего проекта
на Django:

def get_absolute_url(self):
    return '/files/%s/#%s' % (self.category.url, self.url)

>Почитал я этот тред и решил посмотреть в сторону написания SQL-запросов вручную.
Не все так плохо как тут пытаются представить. ORM безусловно замедляет работу с БД. В сравнении с другими SQLAlchemy вполне достойно выглядит.
http://groups.google.com/group/sqlalchemy/browse_thread/thread/9edb24023711968d

Если 90% time spent in SA overhead — это достойно…

>Чтобы можно было, например, передать в шаблон экземпляр класса и вызывать какие-нибудь его методы

ну сделай конструктор, который делает объект по кортежу. Хотя это тоже лишний overhead :)

Кстати, как у джанги дела с производительностью? Судя по блогу Салагаева, явных проблем вроде нет?

>Если 90% time spent in SA overhead — это достойно…
Прочитай весь текст. И не по диагонали. Там говорится при каких условиях это происходит. Или хочется чтоб работало быстро и всегда? Мозги берегем?

Никогда не тестировал производительность Django ORM, так что ничего про его производительность сказать не могу. Однако во время работы с ним я столкнулся с другой проблемой: слишком часто приходится прибегать к написанию SQL вручную (ORM не справляется), а вот создать из результатов запроса обьекты и связать их друг с другом оказывается проблематично.

>Или хочется чтоб работало быстро и всегда?

Хочется, конечно. Особенно в веб приложении. На обычном клиентском на это обычно можно наплевать, а у веба свои тараканы. Запрос, который работает больше полсекунды — катастрофа. ORM, который замедляет работу с базой в 10 раз — тоже катастрофа. Если бы средняя скорость запросов в базу была хотя бы полсекунды, то тормоза алхимии уже не были бы критичными

Метку pyTlons так и не исправили...

captcha: lisped

> Кстати, как у джанги дела с производительностью? Судя по блогу Салагаева, явных проблем вроде нет?

проблем в django orm нет, поскольку ничего, кроме примитивных и, посему, бесполезных, возможностей, оно не имеет и все практически необходимое надо прописывать ручками. а уж как потом это все сопровождать приятно. зато быстро, т...ь. салагаевы, конечно, декларируют возможность использования sqla вместо их пародии на orm, но куда тогда уходят все остальные возможности django сами догадайтесь.

так-что, если вам нужно что-то сложнее user-blog-post, то, при всем богатстве быбора, другой _реальной_ альтернативы pylons пока нет. pylons - не идеальный вариант. но джанги и рельсы - это для тех, кто еле-еле отошел от php и все еще свято верит в "серебряную пулю", которую им вот-вот дадут, стоит лишь немного потерпеть.

>другой _реальной_ альтернативы pylons пока нет

Есть web.py

Мне кажется, что лучше на С++ писать сайты.

Вначале используем какой-нить ORM, потом оптимизируем на SQL`е.

имхо, ORM и чистый SQL - неотьемлемая часть проекта!

PS: от питоновцев как всегда - много вони, а толку нуль. Пишите на рельсах.

>>Мне кажется, что лучше на С++ писать сайты.

Когда кажется, креститься надо!

>PS: от питоновцев как всегда - много вони, а толку нуль. Пишите на рельсах.

Рельсы - кусок дерьма, соси их сам! Такое только врагам и мазохистам можно посоветовать.

Питон и Джанга - таки рулят!
Там где не рулят, ну не не ложится ваша задача на их каркас (бывает) - ну вот там и смотрите на всякое пылонЪ да турбошестерёнки ....
Хотя в глубине души я просто таки уверен - если джанга не помогла то ... то вам и другие фрэймворки только мешать будут!

бизнес-модели на самом деле оперируют объектами. и собственно, для того чтобы хранить состояние объекта ни sql, ни реляционности нафик не нужны -- достаточно тупой сериализации + api для разруливания совместного доступа.

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

поэтому, по-хорошему, от ORM требуется api, который позволяет определять этих самые множества, делать утверждения о принадлежности объектов множествам, дёргать из множеств объеты, и выполнять "групповые" операции над объектами, как элементами множеств. т.е. SQL-подобного api хватит заглаза.

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