Здравствуйте, Cyberax, Вы писали:
C>А зачем ВООБЩЕ нужен "портативный DB API"? Вот этого я не очень понимаю.
Хочу вот так например писать, а не возиться со строками и диалектами SQL-я:
for r in customerTable.select().execute(customerTable.c.last_order < date(1976, 10, 10)).fetchall():
customerTableArchive.insert.execute(r.items())
C>Почти вся его функциональность замечательно делается HQLем, да еще и C>удобнее получается. Тем более что на обобщенном DB API точно так же C>будут недоступны DB-specific фичи, которые используются для оптимизации C>сложных запросов (придется на уровень SQL спускаться).
В SA редко, так как есть Literal Text Blocks.
>> А со сложной моделью тут надо знать >> досконально и очень часто простота в цене. Hibernate весьма не прост: >> http://shinetech.com/display/www/The+Good+News+And+The+Bad+News C>Ну и? Для SqlAlchemy, да даже и для чистого SQL, большая часть того что C>там написана тоже относится.
Там не совсем об этом. В отличии от большинства высокоуровневых языков, где семантика понятна и её влияние на скорость тоже, высокоуровневый ORМ часто создаёт тормоза, по не совсем ясным причинам. Из за этого многие неглупые люди считают, что он вообще не нужeн. Можно не быть таким радикалом, но возможность отказа от такого механизма без отказа от интеграции базы в язык очень полезна. Это можно сделать через API, как в SA или расширив сам язык как в C#(LINQ).
>запросо> C>Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги >> C>почти такие же. Язык запросов только немного поприятнее из-за >> C>динамических фич Питона. >> 1) Нет HQL C>Это плюс?
HQL это DSL для запросов со своим парсером и AST. До него наверное можно добраться, но вряд ли там все просто. В SA дерево запроса конструируется явно, в родной среде, и без всяким синтаксических надстроек. Если нужно, то построить на нем DSL нет никаких проблем. При чем этот DSL можно поднять до уровня бухгалтера Тамары, у которой при виде HQL мозги расплавятся. В самом Питоне это просто не нужно, так как язык выразителен, ну а в Яве без него никуда так как мозги расплавятся у программеров, как ты сам правильно заметил в одном из своих постов.
>> 2) Maштабируется вниз, когда ORM не нужен. C>Тогда зачем брать ORM? Берем iBATIS и не городим огород.
Во-во. Вот если бы Hibernate был написан сверху iBATIS, получилось бы похоже, согласен. Как раз этой модульности, мне в нем и не хватает. Вся штука как раз в том что SA это не только мэппер ala Hibernate, а то как и на чем он сделан. Там он кстати и не один, вроде уже написали ala ActiveRecord и ala SqlObject. Ну они конечно похуже, так как паттерны самого ORM в Hibernate правильней. Так что SA, это как бы мета-мэппер.
>> 3) Простота и как следствия грабли видны быстрее C>Где простота? Не вижу ее.
Меньше кода и слоев. Ну посмотри хоть по глубине стека, а то строки кода считать будет наверное смешно.
>> Встречный вопрос, что в Hibernate такого? C>Очень мощный mapping — пожалуй лучший из тех что я видел, поддержка C>настоящего ORM (включая identity mapping), продуманная схема работы с C>транзакциями, поддержка JTA (но это уже Java-specific), хорошая C>поддержка lazy-loading'а, удобный язык запросов, интеграция с серверами C>приложений.
Ну ты меня словами-то мудренными не пугай, а лучше покажи что он может лучше чем SA. А то тут всё или есть в SA (identity mapping, продуманная схема работы с транзакциями, поддержка lazy-loading, удобный язык запросов) или просто связано с Javaland. Ну так и SA в Питоне не плохо живётся. Скоро говорят добавят в ТurboGears и сделают ролик, как написать ebay.com за двадцать минут.
>> Kэширование? Как уже сказал для меня оно ортогонально, то есть JCA это >> хорошо, но встраивать в мэппер не обязательно и даже вредно. C>Нет, кэширование как раз должно быть на уровне mapping'а.
Тут спорит не буду, наверное от задачи зависит. В моей области нуждающиеся в кэширование объекты очень тяжёлые, их руками надо настраивать после любого маппера. А все лёгкое движок базы должен сам делать без моих подсказок. И проблем с транзактностью, которой забиты JAVA приложения, хотя тут дело конечно в основном в руках разработчиков, а не в JCA.
novitk wrote: > C>А зачем ВООБЩЕ нужен "портативный DB API"? Вот этого я не очень понимаю. > Хочу вот так например писать, а не возиться со строками и диалектами SQL-я: > for r in customerTable.select().execute(customerTable.c.last_order < date(1976, 10, 10)).fetchall(): > customerTableArchive.insert.execute(r.items())
List list = s.createCriteria(Customer.class)
.add(Expression.less("last_order", Calendar("10:10:1976")))
.list();
...
Кстати, все это выражение неплохо бы записать в виде одного оператора. А
то с большим количеством Customer'ов будет очень неоптимальная работа.
> C>Почти вся его функциональность замечательно делается HQLем, да еще и > C>удобнее получается. Тем более что на обобщенном DB API точно так же > C>будут недоступны DB-specific фичи, которые используются для оптимизации > C>сложных запросов (придется на уровень SQL спускаться). > В SA редко, так как есть Literal Text Blocks.
И что, в LTB ты пишешь не на SQL?
> C>Ну и? Для SqlAlchemy, да даже и для чистого SQL, большая часть того что > C>там написана тоже относится. > Там не совсем об этом. В отличии от большинства высокоуровневых языков, > где семантика понятна и её влияние на скорость тоже, высокоуровневый ORМ > часто создаёт тормоза, по не совсем ясным причинам.
Сам по себе ORM — вряд ли. Тормоза создает база данных, семантика работы
которой отличается от семантики обычного кода.
У тебя в твоем примере с SA это, кстати, тоже есть. Ты совершенно зря
тянешь на клиент данные, чтобы тут же их вставить обратно в базу.
> Из за этого многие > неглупые люди считают, что он вообще не нужeн. Можно не быть таким > радикалом, но возможность отказа от такого механизма без отказа от > интеграции базы в язык очень полезна. Это можно сделать через API, как в > SA или расширив сам язык как в C#(LINQ).
И будут ну абсолютно те же самые проблемы. Только с видом в профиль —
что уже демонстрирует твой код.
> C>Это плюс? > HQL это DSL для запросов со своим парсером и AST. До него наверное можно > добраться, но вряд ли там все просто.
В HQL есть Query by Criteria, в котором ты точно так же создаешь запрос
в виде AST.
> В самом Питоне это просто не нужно, так как язык > выразителен, ну а в Яве без него никуда так как мозги расплавятся у > программеров, как ты сам правильно заметил в одном из своих постов.
Ну-ну. У меня наоборот от уродливого синтаксиса запросов в SqlAlchemy
мозги плавятся.
Видно у Питонистов расплавились мозги при попытке написать простенький
текстовый парсер.
>> > 2) Maштабируется вниз, когда ORM не нужен. > C>Тогда зачем брать ORM? Берем iBATIS и не городим огород. > Во-во. Вот если бы Hibernate был написан сверху iBATIS, получилось бы > похоже, согласен. Как раз этой модульности, мне в нем и не хватает.
Я просто не понял — ЗАЧЕМ добавлять в Hibernate еще и iBATIS? Нужен DB
API — берем iBATIS и не занимаемся фигней. С Hibernate он сочетался бы
очень плохо, прежде всего из-за разных стратегий использования объектов.
Например, Hibernate гарантирует identity-мэпинг для объектов в одной
сессии. То есть:
Для iBATIS такой гарантии уже нет. Если попытаться добавить ее в iBATIS
— получим Hibernate, и наоборот.
> Меньше кода и слоев. Ну посмотри хоть по глубине стека, а то строки кода > считать будет наверное смешно.
Где меньше кода? А глубина стека — вообще не показатель.
> Ну ты меня словами-то мудренными не пугай, а лучше покажи что он может > лучше чем SA.
Хотя бы: часть фич, связанных с сессиями и транзакциями — пока в Alpha.
Сама реализация работы с сессиями тоже немного отличается от Hibernate.
> А то тут всё или есть в SA (identity mapping, продуманная > схема работы с транзакциями, поддержка lazy-loading, удобный язык > запросов) или просто связано с Javaland.
Язык запросов — HQL мощнее, да и богаче, Lazy-loading лучше продуман (я
очень удивился тому, что SqlAlchemy возвращала пустой список при ленивой
загрузке, если сессия была завершена).
> И проблем с транзактностью, которой забиты > JAVA приложения, хотя тут дело конечно в основном в руках разработчиков, > а не в JCA.
Понимаешь, я пока не знаю как в Python'е сделать распределенную
транзакцию между JMX (это система сообщений) и базой данных. А вот у
меня в Java — это повседневно используемая и важнейшая фича.
А инсерт-то где?
C>И что, в LTB ты пишешь не на SQL?
При чем здесь SQL? Это простой способ вставить что-то очень специальное не ломая концепта, если ну очень нужно.
C>Сам по себе ORM — вряд ли. Тормоза создает база данных, семантика работы C>которой отличается от семантики обычного кода.
Разговор в статье идем именно о тормозах связанных с ORM, а не с мировыми проблемами.
C>И будут ну абсолютно те же самые проблемы. Только с видом в профиль — C>что уже демонстрирует твой код.
Кто сказал, что Customer и CustomerArchive живет в одной базе?
Или что Customer-a не надобно препроцессать перед инсертом?
Это же пример. Ну уж если так нужна скорость, то вот:
Ну и как сие в H. будет выглидеть?
>> C>Это плюс? >> HQL это DSL для запросов со своим парсером и AST. До него наверное можно >> добраться, но вряд ли там все просто. C>В HQL есть Query by Criteria, в котором ты точно так же создаешь запрос C>в виде AST.
Тут согласен, недосмотрел, можно DSL для тети Томары построить. У нас тут это не пользуют, так как код типа мучения котов в главе про критерии смотрится ужасно. Я думаю HQL-я бы не было, если был бы operator overloading в Яве. Ну, а так костыль. Кто нибудь с матрицами в Яве работает интересно? Там то же надо парсер Матлаба встраивать, что бы мозги не поплыли?
C>Ну-ну. У меня наоборот от уродливого синтаксиса запросов в SqlAlchemy C>мозги плавятся. C>Видно у Питонистов расплавились мозги при попытке написать простенький C>текстовый парсер.
А в чем сложность в SA? Утверждение что на Питоне написать парсер сложнее чем на Яве смешно.
C>Я просто не понял — ЗАЧЕМ добавлять в Hibernate еще и iBATIS? Нужен DB C>API — берем iBATIS и не занимаемся фигней. С Hibernate он сочетался бы C>очень плохо, прежде всего из-за разных стратегий использования объектов.
Да потому что он там уже есть, тебе просто об этом не сказали.
C>Например, Hibernate гарантирует identity-мэпинг для объектов в одной C>сессии. То есть: C>Для iBATIS такой гарантии уже нет. Если попытаться добавить ее в iBATIS C>- получим Hibernate, и наоборот.
Не в том речь. Давай пример попробую:
Экскаватору главное конечно копать, но и другие операции делать иногда полезно. Так вот у экскаватора H. гусеници работают только когда копаешь, а что бы с места на места переехать или там землу утоптать нужен тягач iBATIS или трактор JDBC. Ну а у трактора другой бензин, водила там нужен с другими правами и т.д. и т.п.
То есть мне непонятно почему ОRМ надо делать на JDBC, a не на каком нибудь нормальном API, где таблици, колонки и запросы нормально представлены и от деталей движка изолированны.
>> Меньше кода и слоев. Ну посмотри хоть по глубине стека, а то строки кода >> считать будет наверное смешно. C>Где меньше кода? А глубина стека — вообще не показатель.
А какие тогда объективные критерии простоты?
Число строк ползовательского кода для выполнения задачи? Дак тут же SA/Python рулит по черному...
C>Язык запросов — HQL мощнее, да и богаче,
Пример богатства и мощи в студию.
C>Lazy-loading лучше продуман (я C>очень удивился тому, что SqlAlchemy возвращала пустой список при ленивой C>загрузке, если сессия была завершена).
Ну баг наверное, бывает. То что SА менее отлажен чем H cогласен, он ведь совсем новый.
C>Понимаешь, я пока не знаю как в Python'е сделать распределенную C>транзакцию между JMX (это система сообщений) и базой данных. А вот у C>меня в Java — это повседневно используемая и важнейшая фича.
Никак, поскольку ХА поддержки нет. Можно взять и написать враппер к С-шному TPM API (какой там у тебя? Tuxedo?), но это видно никому не нужно. Только при чем здесь Hibernate?
novitk wrote: > C>List list = s.createCriteria(Customer.class) > C> .add(Expression.less("last_order", Calendar("10:10:1976"))) > C> .list(); > C>... > C> > А инсерт-то где?
По памяти не вспомню. Будет примерно так же выглядеть.
Что-то типа:
for(Customer f : list) s.insert(f);
> C>И что, в LTB ты пишешь не на SQL? > При чем здесь SQL? Это простой способ вставить что-то очень специальное > не ломая концепта, если ну очень нужно.
А вставка на чем? И что будет если я вставлю "; DROP DATABASE"?
> C>Сам по себе ORM — вряд ли. Тормоза создает база данных, семантика работы > C>которой отличается от семантики обычного кода. > Разговор в статье идем именно о тормозах связанных с ORM, а не с > мировыми проблемами.
Чего в самом ORM тормозить? Там кода-то с циклами не так много.
> C>И будут ну абсолютно те же самые проблемы. Только с видом в профиль — > C>что уже демонстрирует твой код. > Кто сказал, что Customer и CustomerArchive живет в одной базе?
А как у нас там с транзакциями тогда? Да и у меня все будет нормально,
Customer'ы — это обычные объекты:
for(Customer f : list) s_another.insert(f);
s_another — сессия с другой базой.
> Или что Customer-a не надобно препроцессать перед инсертом?
Ну тогда да.
> Это же пример. Ну уж если так нужна скорость, то вот: > [python] > CustomerArchive.insert(values = \ > Customer.select().where(Customer.c.last_order == date(1976, 10, 10) > ).execute() > [python] > Ну и как сие в H. будет выглидеть?
Абсолютно так же. Criteria queries можно использовать в insert-операторах.
> C>В HQL есть Query by Criteria, в котором ты точно так же создаешь запрос > C>в виде AST. > Тут согласен, недосмотрел, можно DSL для тети Томары построить. У нас > тут это не пользуют, так как код типа мучения котов в главе про критерии > смотрится ужасно. Я думаю HQL-я бы не было, если был бы operator > overloading в Яве.
Ну так я сказал же — язык запросов в SqlAlchemy иногда выглядит немного
красивее из-за фич языка Питон. Но ничего революционного.
> Ну, а так костыль. Кто нибудь с матрицами в Яве > работает интересно? Там то же надо парсер Матлаба встраивать, что бы > мозги не поплыли?
А как там на Питоне с распределенными транзакциями с SAP, JMX и DB? Тоже
руками делать?
> А в чем сложность в SA? Утверждение что на Питоне написать парсер > сложнее чем на Яве смешно.
Пародия на твой наезд.
> C>Я просто не понял — ЗАЧЕМ добавлять в Hibernate еще и iBATIS? Нужен DB > C>API — берем iBATIS и не занимаемся фигней. С Hibernate он сочетался бы > C>очень плохо, прежде всего из-за разных стратегий использования объектов. > Да потому что он там уже есть, тебе просто об этом не сказали.
iBATIS???
> То есть мне непонятно почему ОRМ надо делать на JDBC, a не на каком > нибудь нормальном API, где таблици, колонки и запросы нормально > представлены и от деталей движка изолированны.
А ЗАЧЕМ? Это ничего не даст для ORM, так как нет разницы как работать с
таблицами — через DB API или JDBC.
> А какие тогда объективные критерии простоты? > Число строк ползовательского кода для выполнения задачи? Дак тут же > SA/Python рулит по черному...
Вряд ли. Точнее может быть немного меньше из-за большей лаконичности
Python'а, но скорее всего даже не в разы.
> C>Язык запросов — HQL мощнее, да и богаче, > Пример богатства и мощи в студию.
Посмотри примеры с наследованием и с join'ами.
> C>Lazy-loading лучше продуман (я > C>очень удивился тому, что SqlAlchemy возвращала пустой список при ленивой > C>загрузке, если сессия была завершена). > Ну баг наверное, бывает. То что SА менее отлажен чем H cогласен, он ведь > совсем новый.
Ну вот года через полтора посмотрим.
> C>Понимаешь, я пока не знаю как в Python'е сделать распределенную > C>транзакцию между JMX (это система сообщений) и базой данных. А вот у > C>меня в Java — это повседневно используемая и важнейшая фича. > Никак, поскольку ХА поддержки нет. Можно взять и написать враппер к > С-шному TPM API (какой там у тебя? Tuxedo?), но это видно никому не > нужно. Только при чем здесь Hibernate?
Мне вот XA очень даже нужен. Например, чтобы транзакционно делать
апдейты в базе и отсылать об этом JMX-оповещения клиентам. Никакого
Tuxedo для этого не нужно (чур меня, чур!), достаточно JBoss Transactions.
Alex EXO wrote: > C>Как вариант неплохо. А как overhead от межпроцессного общения? Не заметно? > Не заметно. Запросы к базе всяко больше едят.
А как именно все организовали?
Так работать не будет так как вставит в Customer, a не в CustomerArchive.
>> C>И что, в LTB ты пишешь не на SQL? >> При чем здесь SQL? Это простой способ вставить что-то очень специальное >> не ломая концепта, если ну очень нужно. C>А вставка на чем? И что будет если я вставлю "; DROP DATABASE"?
Тут какой-то намёк на SQL injection. Не догоняю к чему...
>> Ну и как сие в H. будет выглядеть? C>Абсолютно так же. Criteria queries можно использовать в insert-операторах.
Ткни плиз носом в документацию, может я не понимаю чего? Ну как сделать простое копирование как я предложил без создания двух одинаковых классов замэпанных на две разные таблицы, а стало быть и прогонна через память клиента.
C>А как там на Питоне с распределёнными транзакциями с SAP, JMX и DB? Тоже C>руками делать?
Да есть оно, все нормально, я погорячился: здесь. Просто я в гробу видал все эти заморочки и так проблем хватает. Если правильными руками делать, проблем не будет с хорошей вероятностью — ставь коммиты близко, делов-то.
Ладно предлагая мир, все нормально в H. Раньше даже нравилось, но теперь он стал как-то не нужен, как впрочем и вся Ява. Но это личное, у кого-то оно наверно по-другому...
novitk wrote: > C>for(Customer f : list) s.insert(f); > Так работать не будет так как вставит в Customer, a не в CustomerArchive.
См. ниже.
Заменяешь s на s_another — и вперед. Customer — это обычный объект.
> C>А вставка на чем? И что будет если я вставлю "; DROP DATABASE"? > Тут какой-то намёк на SQL injection. Не догоняю к чему...
Именно. Что будет, если я вставлю "; DROP DATABASE" в literal-блок? А
как там с байндингами?
>> > Ну и как сие в H. будет выглядеть? > C>Абсолютно так же. Criteria queries можно использовать в insert-операторах. > Ткни плиз носом в документацию, может я не понимаю чего? Ну как сделать > простое копирование как я предложил без создания двух одинаковых классов > замэпанных на две разные таблицы, а стало быть и прогонна через память > клиента.
В пределах одной базы, к сожалению. Между базами — никак.
> C>А как там на Питоне с распределёнными транзакциями с SAP, JMX и DB? Тоже > C>руками делать? > Да есть оно, все нормально, я погорячился: здесь > <http://ralf.freezope.org/software/>. Просто я в гробу видал все эти > заморочки и так проблем хватает. Если правильными руками делать, проблем > не будет с хорошей вероятностью — ставь коммиты близко, делов-то.
Это будет уже игра "повезет — не повезет". А нужно 100% надежность.
> Ладно предлагая мир, все нормально в H. Раньше даже нравилось, но теперь > он стал как-то не нужен, как впрочем и вся Ява. Но это личное, у кого-то > оно наверно по-другому...
Ок
Здравствуйте, Cyberax, Вы писали: C>А как именно все организовали?
Дак вроде бы все просто. Спроси конкретнее...
на стороне java : hibernate + xfire (хотя несколько пожалел, что взял hibernate а не ibatis)
на стороне ruby : собственно RoR + rsoap ну и wsdlToRuby для генерации классов.
