Здравствуйте, Alexey Chen, Вы писали:

AC>Вот пытаюсь достучаться до модерторов с вопросом: как бы так сделать чтобы на RSDN был раздел по питону — молчат.

Не знаю как по питону, а вот по динамическим языкам форум давно уже назрел.

Здравствуйте, DaBro, Вы писали:

DB>Решил тут посмотреть на этот язык.

DB>Да и вообще интересно ваше мнение о применимости языка. Мне пока видится что это всякие скрипты для команды разработки — deploy etc, а также клей для тонкой настройки приложений.

Знаю один большой проект на питоне. Civilization IV называется..

Здравствуйте, ie, Вы писали:

ie>Не знаю как по питону, а вот по динамическим языкам форум давно уже назрел.

Боюсь в нем будет филиал Философии программирования.
Хотя одна радость есть. Это будет место где можно будет пообщаться с FR и eao197 без меня.

Аноним wrote:
> Фишек в Hibernate действительно куча — согласен. Ну тут как с плюсами.
> При виде всех этих прибамбасов народ начинает теряться, а как собственно
> делать? Есть конечно рекомендации всяких умных дядек, но это же все
> теория. Оно конечно весело, но для дела не очень полезно, так как база
> данных аспект, повторюсь, мелкий. Все эти хитрые мэппинги, HQL-и, тонны
> ХМЛ-я, у меня ковырять ни времени ни желания нет. А "тупым индусам" это
> отдать страшно, по тому как это не кнопки на формы клепать.
Hibernate элементарно можно начать использовать при минимальных знаниях
того, что такое "реляционная модель". Мэпинги там абсолютно несложные,
еще в первой Hibernate я их освоил за час.

> Грубо говоря я за заточенный инструмент, а не за букет в одном флаконе.
> По этим причинам я и предпочитаю движки которые дают именно реляционную
> алгебру (LINQ, SqlAlchemy), а ORM это настройка, как и кэширование
> кстати. Не нравиться ихний ORM, могу заделать свой или вообще обойтись.
Вообще-то, к реляционной алгебре SqlAlchemy имеет отношение точно такое
же, как и Hinernate.

> Я впрочем не считаю Hibernate отстоем, и если нужно "сидеть" в Java-e
> пользовал бы именно его. Просто сейчас после появления SqlAlchemy, с
> сострадаем смотру на людей которые делают обвязку для базы на оном.
Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги
почти такие же. Язык запросов только немного поприятнее из-за
динамических фич Питона.

Решил тут посмотреть на этот язык.
Уж больно много про него сказано/написано. Да и голову размять немного полезно.

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

Расскажите, кто работал с Python — какого оно? Какие объемы проектов делали, что за проблемы были.

Да и вообще интересно ваше мнение о применимости языка. Мне пока видится что это всякие скрипты для команды разработки — deploy etc, а также клей для тонкой настройки приложений.

Также при моей невнимательности можно только по TDD работать — иначе очень быстро все так запутывается, что тушите свет. Может быть не привык еще.

Кстати среды для unit тестирования тоже не нашел нормальной. Какая наиболее удобна и популярна сейчас?
Да и IDE после VS2005 мягко говоря неудобный (опять же смотрел несколько бесплатных продуктов и у всех что-нибудь да отваливается).

Вобщем все это непривычно, но хочется разобраться, что за змей такой.

Расскажите, а?

Здравствуйте, DaBro, Вы писали:

DB>Решил тут посмотреть на этот язык.
DB>Уж больно много про него сказано/написано. Да и голову размять немного полезно.

DB>Язык конечно симпатичный — чем-то он мне smalltalk напомнил.
DB>Но вот беда — настолько уже привык к статическому контролю типов и более строгим правилам, что вкрались у меня сомнения — а можно ли сделать на этом языке что-либо надежное за приемлемое время.

Можно, реально похоже надежность мало зависит от типизации.

DB>Расскажите, кто работал с Python — какого оно? Какие объемы проектов делали, что за проблемы были.

Порядка 20000 строк на питоне + 10000 библиотек на с++.
Проблемы были только со стороними (PIL) библиотеками. Пришлось пару баг репортов им послать.

DB>Да и вообще интересно ваше мнение о применимости языка. Мне пока видится что это всякие скрипты для команды разработки — deploy etc, а также клей для тонкой настройки приложений.

Также полное написание небольших игр на питоне (графика и другой низкий уровень библиотека на C++).

DB>Также при моей невнимательности можно только по TDD работать — иначе очень быстро все так запутывается, что тушите свет. Может быть не привык еще.

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

DB>Кстати среды для unit тестирования тоже не нашел нормальной. Какая наиболее удобна и популярна сейчас?

Средами не пользовался но чем не подходит стандартный модуль unittest?

DB>Да и IDE после VS2005 мягко говоря неудобный (опять же смотрел несколько бесплатных продуктов и у всех что-нибудь да отваливается).

Хорошее IDE это WingIDE правда оно платное но не дорогое.

Писал на Python-е систему репликации.
Несколько скриптов для крона и svn (каждый <20 модулей)

На PyQt — помошьник для перевода специализированной базы.
Собственно в начале использовал PyQt для прототипирования юзабилити, собираясь в дальнейшем перевесть на С++ чтобы не тормозило.
Переводить не потребывалось!
Общее увеличение производительности переводчика более чем на порядок.

Здравствуйте, DaBro, Вы писали:

DB>Но вот беда — настолько уже привык к статическому контролю типов и более строгим правилам, что вкрались у меня сомнения — а можно ли сделать на этом языке что-либо надежное за приемлемое время.
DB>Расскажите, кто работал с Python — какого оно? Какие объемы проектов делали, что за проблемы были.

Рассказываю: на плюсатах пишу всё меньше и меньше, по тому как на питоне сухо и мяки НО, заметь я вообще человек со странностями, мне SmallTalk нравится

Если серьёзно, не только можно на нём писать, но и нужно. Язык не только удобный синтаксически но и очень мощный в плане парадигм программирования. А статический контроль типов — ИМХО, от этого только головная боль и синтаксический онанизм в духе С++, но в незащищённой среде на голом железе иного пути нет.

Ещё очень важно что язык легко расширяем и поддаётся тонкой настройке под конкретную задачу.

Одно удручает, не смотря на то что про него много сказанно, python слабо популизируется и рекламируется, как унивирсальное средство разработки — а значит и развивается существенно медленнее чем мог бы.

Вот пытаюсь достучаться до модерторов с вопросом: как бы так сделать чтобы на RSDN был раздел по питону — молчат. Наверное у себя на сайте делать придётся.

Здравствуйте, FR, Вы писали:

FR>Хорошее IDE это WingIDE правда оно платное но не дорогое.
Я komodo предпочитаю, но правда и пишу я не только на питоне

Здравствуйте, ie, Вы писали:

AC>>Вот пытаюсь достучаться до модерторов с вопросом: как бы так сделать чтобы на RSDN был раздел по питону — молчат.
ie>Не знаю как по питону, а вот по динамическим языкам форум давно уже назрел.

Дык, всёравно молчат

А в форуме по динмическим, можно было бы ещё и всякие интересности обсуждать типа self'a, динамической компиляции, другого нежели в С++ метапрограммирования, аспектов... Причём не в теориии, но в практической плоскости. Однака, сдаётся мне мало нас таких, а чтобы было много, нужно чтобы было средство популизации, а для этого нужно чтобы было много ... в общем типа замкнутого круга получается

ЗЫ.
про ruby специально не говорю, у него свои апологеты есть.

Здравствуйте, Alexey Chen, Вы писали:

AC>А в форуме по динмическим, можно было бы ещё и всякие интересности обсуждать типа self'a,

Так и вижу self vs. Ruby или бои без правил с eao197!

AC>динамической компиляции, другого нежели в С++ метапрограммирования, аспектов...

Для этого как раз текущий форум и редназначен. Все это как бы к скриптам прямого отношения не имеет.

AC> Причём не в теориии, но в практической плоскости.

Ага. А тут значич в теории все обсуждается?

AC> Однака, сдаётся мне мало нас таких, а чтобы было много, нужно чтобы было средство популизации, а для этого нужно чтобы было много ... в общем типа замкнутого круга получается

Пишите статьи. Мы с удовольствием опубликуем.

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

AC>про ruby специально не говорю, у него свои апологеты есть.

Да и мы его хорошо знаем и любим.

Здравствуйте, VladD2, Вы писали:

AC>>А в форуме по динмическим, можно было бы ещё и всякие интересности обсуждать типа self'a,
AC>>динамической компиляции, другого нежели в С++ метапрограммирования, аспектов...
VD>Для этого как раз текущий форум и редназначен. Все это как бы к скриптам прямого отношения не имеет.

Если обсуждать в форуме 'декларативное программирование' аспекты в питоне ещё можно, то реализации персистентности или UI — нет, целевая аудитория питона сюда не пойдёт ИМХО, форум не тот.

AC>> Причём не в теориии, но в практической плоскости.
VD>Ага. А тут значич в теории все обсуждается?

Да. Как взгляд со стороны, я же в основном читатель

AC>> Однака, сдаётся мне мало нас таких, а чтобы было много, нужно чтобы было средство популизации, а для этого нужно чтобы было много ... в общем типа замкнутого круга получается
VD>Пишите статьи. Мы с удовольствием опубликуем.
VD>На форум скрипты явно не тянут. Все что касается веба можно обсуждать в соотвествующем оруме. Метапрограммирование и аспектное программирование тут. В прочем, открывайте глосование и если много народа прогалосует за форум, то можно и подумать. Ничего невозможного нет.

Хм, это мнение редакции или отдельно взятого модератора? Как-то на письма мне никто не ответил даже простого 'нет'.
ИМХО, Java тот же скрипт, только её пиарили много и долго, как результат развивалась она быстрее, а уж как пиарили C#... Но твою точку зрения я понял: создайте коммунити и приводите к нам — точка зрения понятна и оправданна.

Здравствуйте, Alexey Chen, Вы писали:

AC>Если обсуждать в форуме 'декларативное программирование' аспекты в питоне ещё можно, то реализации персистентности или UI — нет, целевая аудитория питона сюда не пойдёт ИМХО, форум не тот.

Для UI есть соотвествующие форумы.

В общем, не надо выдумывать. Если речь идет о Питоне, то не надо приделывать с боку темы вроде метапрограммирования.

AC>Да. Как взгляд со стороны, я же в основном читатель

Для меня как глядящего со стороны вообще смысла в Питне нет. Это же не повод хоронить язык? Многие из тут обитающих применяют обсуждаемое на практике.

AC>Хм, это мнение редакции или отдельно взятого модератора?

Смотря по какому поводу.

AC>Как-то на письма мне никто не ответил даже простого 'нет'.

Я и писем не видел. Собственно вопрос с форумами (если о нем речь) решается очень просто. Если появляется значительный трафик по некторому вопросу (причем обособленный, а не в контексте других проблем), то обдумывается создание форума. А просто по просбам трудящихся форумы создаются очень редко.

AC>ИМХО, Java тот же скрипт,

Ну, на то оно и твое имхо. Причем оно скорее аргумент чтобы твое мнение игнорировать, так как оно не соотвествует ни риальному положению вещей, ни обещпринятой терминалогии. Кто же тебя знает, может ты под скриптом ОКамл, к примеру, понимаешь?

AC> только её пиарили много и долго, как результат развивалась она быстрее, а уж как пиарили C#... Но твою точку зрения я понял: создайте коммунити и приводите к нам — точка зрения понятна и оправданна.

Создавать в общем-то ничего не надо. Но создавать форум в котором будет 5 вопросов в месяц мы точно не будет. Форумы требуют модерирования и т.п. И мертвяки усложняют жизнь.

В общем, самый простой способ подвигнуть нас к созданию новго форума — это создать голосование. Ну, или просто задавать много вопросов именно по скриптовым языкам.

IMHO
Хорошо использовать для слоев баз данных и веб сервисов, то есть обвязка быстрых движков на плюсах. С базами если использовать что-то типа SqlAlchemy, то Hibernate и ActiveRecord отдыхают. И для веба качественного инструментария завались, при чем можно выбрать то что нужно, а не брать все скопом, как с RoR. Об WingIDE тут уже написано, подтверждаю — вещь толковая.

Если действительно нужна надёжность в большой системе, то нужно писать юнит тесты. Так как разработка на П. идёт быстрее, то времени на них больше.

Проблема для меня одна — скорость. Если нужно быстро дробить числа и нет готовых компонент вроде NumPy, то придеться ковырять плюсы, а интеграция добавит сложность и время.

novitk wrote:
> Хорошо использовать для слоев баз данных и веб сервисов, то есть обвязка
> быстрых движков на плюсах. С базами если использовать что-то типа
> SqlAlchemy, то Hibernate и ActiveRecord отдыхают.
При всем моем уважении к Python, сравнивать SqlAlchemy _значительно_
проигрывает Hibernate по многим параметрам. В Hibernate намноно больше
типов мэппинга, лучше проработаны механизмы кэширования и т.п.

А вот лучше чем ActiveRecord — это точно.

Здравствуйте, Cyberax, Вы писали:
C>А вот лучше чем ActiveRecord — это точно.

Кстати сейчас сделал в текущем проекте "двухслойный" сервер приложений:

1. Нижний слой — web-сервисные модули ( на java + hibernate ), реализующие
хранение бизнес-обектов и набор операций над ними.

2. Верхний слой — общая логика и пользовательский интерфейс ( на RubyOnRails ).
Эти "модули отображения" не имеют своих "хранимых" объектов и своей
базы данных, а соответсвенно их можно запускать сколько угодно копий
паралельно (для масштабирования решения).

C>При всем моем уважении к Python, сравнивать SqlAlchemy _значительно_
C>проигрывает Hibernate по многим параметрам. В Hibernate намноно больше
C>типов мэппинга, лучше проработаны механизмы кэширования и т.п.

Поясню свой флэйм на Hibernate. Изначально скажу, что я в нем не эксперт, но имел счастье посмотреть как используется в похожем на мой по тематике проекте, где моя роль ограничивалась советами/критикой по дизайну. В этой области базы данных это, ну отсилы 15% задачи, так что для меня главные критерии хорошего инструмента — быстрая разработка и что бы граблей было поменьше.

Фишек в Hibernate действительно куча — согласен. Ну тут как с плюсами. При виде всех этих прибамбасов народ начинает теряться, а как собственно делать? Есть конечно рекомендации всяких умных дядек, но это же все теория. Оно конечно весело, но для дела не очень полезно, так как база данных аспект, повторюсь, мелкий. Все эти хитрые мэппинги, HQL-и, тонны ХМЛ-я, у меня ковырять ни времени ни желания нет. А "тупым индусам" это отдать страшно, по тому как это не кнопки на формы клепать.

Грубо говоря я за заточенный инструмент, а не за букет в одном флаконе. По этим причинам я и предпочитаю движки которые дают именно реляционную алгебру (LINQ, SqlAlchemy), а ORM это настройка, как и кэширование кстати. Не нравиться ихний ORM, могу заделать свой или вообще обойтись.

Я впрочем не считаю Hibernate отстоем, и если нужно "сидеть" в Java-e пользовал бы именно его. Просто сейчас после появления SqlAlchemy, с сострадаем смотру на людей которые делают обвязку для базы на оном.

Alex EXO wrote:
> Кстати сейчас сделал в текущем проекте "двухслойный" сервер приложений:
> 1. Нижний слой — web-сервисные модули ( на java + hibernate ), реализующие
> хранение бизнес-обектов и набор операций над ними.
> 2. Верхний слой — общая логика и пользовательский интерфейс ( на
> RubyOnRails ).
> Эти "модули отображения" не имеют своих "хранимых" объектов и своей
> базы данных, а соответсвенно их можно запускать сколько угодно копий
> паралельно (для масштабирования решения).
Как вариант неплохо. А как overhead от межпроцессного общения? Не заметно?

Здравствуйте, Cyberax, Вы писали:

C>Hibernate элементарно можно начать использовать при минимальных знаниях
C>того, что такое "реляционная модель". Мэпинги там абсолютно несложные,
C>ещё в первой Hibernate я их освоил за час.

Ну да, и "hello, world" на плюсах, то же просто и понятно. Если модель простая, то ORM вообще не нужен, а нужен удобный портативный DB-API, о котором в SqlAlchemy пол книги, а в Hibernate мне с ходу не понятно, как что-то с базой сделать без создания всяких PoJo, XML-a и прочей хрени, не погружаясь, так сказать в JDBC. А со сложной моделью тут надо знать досконально и очень часто простота в цене. Hibernate весьма не прост:
http://shinetech.com/display/www/The+Good+News+And+The+Bad+News

C>Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги
C>почти такие же. Язык запросов только немного поприятнее из-за
C>динамических фич Питона.

1) Нет HQL
2) Maштабируется вниз, когда ORM не нужен.
3) Простота и как следствия грабли видны быстрее

Встречный вопрос, что в Hibernate такого?
Kэширование? Как уже сказал для меня оно ортогонально, то есть JCA это хорошо, но встраивать в мэппер не обязательно и даже вредно.

Inheritance mapping strategies? От лукавого все это...Проблем больше, чем удобства.

Что там еще?

novitk wrote:
> Ну да, и "hello, world" на плюсах, то же просто и понятно. Если модель
> простая, то ORM вообще не нужен, а нужен удобный портативный DB-API, о
> котором в SqlAlchemy пол книги, а в Hibernate мне с ходу не понятно, как
> что-то с базой сделать без создания всяких PoJo, XML-a и прочей хрени,
> не погружаясь, так сказать в JDBC.
А зачем ВООБЩЕ нужен "портативный DB API"? Вот этого я не очень понимаю.

Почти вся его функциональность замечательно делается HQLем, да еще и
удобнее получается. Тем более что на обобщенном DB API точно так же
будут недоступны DB-specific фичи, которые используются для оптимизации
сложных запросов (придется на уровень SQL спускаться).

> А со сложной моделью тут надо знать
> досконально и очень часто простота в цене. Hibernate весьма не прост:
> http://shinetech.com/display/www/The+Good+News+And+The+Bad+News
Ну и? Для SqlAlchemy, да даже и для чистого SQL, большая часть того что
там написана тоже относится.

> C>Ну так что в SqlAlchemy такого? Ну не вижу ничего абсолютно. Мэпинги
> C>почти такие же. Язык запросов только немного поприятнее из-за
> C>динамических фич Питона.
> 1) Нет HQL
Это плюс?

> 2) Maштабируется вниз, когда ORM не нужен.
Тогда зачем брать ORM? Берем iBATIS и не городим огород.

> 3) Простота и как следствия грабли видны быстрее
Где простота? Не вижу ее.

> Встречный вопрос, что в Hibernate такого?
Очень мощный mapping — пожалуй лучший из тех что я видел, поддержка
настоящего ORM (включая identity mapping), продуманная схема работы с
транзакциями, поддержка JTA (но это уже Java-specific), хорошая
поддержка lazy-loading'а, удобный язык запросов, интеграция с серверами
приложений.

> Kэширование? Как уже сказал для меня оно ортогонально, то есть JCA это
> хорошо, но встраивать в мэппер не обязательно и даже вредно.
Нет, кэширование как раз должно быть на уровне mapping'а.

Здравствуйте, 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-мэпинг для объектов в одной
сессии. То есть:

SomeObject o1=s.load(SomeObject.class,1);
SomeObject o2=s.load(SomeObject.class,1);

assert o1==o2; //Всегда выполняется

Для iBATIS такой гарантии уже нет. Если попытаться добавить ее в iBATIS
— получим Hibernate, и наоборот.

> Меньше кода и слоев. Ну посмотри хоть по глубине стека, а то строки кода
> считать будет наверное смешно.
Где меньше кода? А глубина стека — вообще не показатель.

> Ну ты меня словами-то мудренными не пугай, а лучше покажи что он может
> лучше чем SA.
Хотя бы: часть фич, связанных с сессиями и транзакциями — пока в Alpha.
Сама реализация работы с сессиями тоже немного отличается от Hibernate.

> А то тут всё или есть в SA (identity mapping, продуманная
> схема работы с транзакциями, поддержка lazy-loading, удобный язык
> запросов) или просто связано с Javaland.
Язык запросов — HQL мощнее, да и богаче, Lazy-loading лучше продуман (я
очень удивился тому, что SqlAlchemy возвращала пустой список при ленивой
загрузке, если сессия была завершена).

> И проблем с транзактностью, которой забиты
> JAVA приложения, хотя тут дело конечно в основном в руках разработчиков,
> а не в JCA.
Понимаешь, я пока не знаю как в Python'е сделать распределенную
транзакцию между JMX (это система сообщений) и базой данных. А вот у
меня в Java — это повседневно используемая и важнейшая фича.

Здравствуйте, Cyberax, Вы писали:

C>Как вариант неплохо. А как overhead от межпроцессного общения? Не заметно?

Не заметно. Запросы к базе всяко больше едят.

C>

C>List list = s.createCriteria(Customer.class)
C>    .add(Expression.less("last_order", Calendar("10:10:1976")))
C>    .list();
C>...
C>

А инсерт-то где?

C>И что, в LTB ты пишешь не на SQL?

При чем здесь SQL? Это простой способ вставить что-то очень специальное не ломая концепта, если ну очень нужно.

C>Сам по себе ORM — вряд ли. Тормоза создает база данных, семантика работы
C>которой отличается от семантики обычного кода.

Разговор в статье идем именно о тормозах связанных с ORM, а не с мировыми проблемами.

C>И будут ну абсолютно те же самые проблемы. Только с видом в профиль —
C>что уже демонстрирует твой код.

Кто сказал, что Customer и CustomerArchive живет в одной базе?
Или что Customer-a не надобно препроцессать перед инсертом?
Это же пример. Ну уж если так нужна скорость, то вот:

[python]
CustomerArchive.insert(values = \
Customer.select().where(Customer.c.last_order == date(1976, 10, 10)
).execute()
[python]

Ну и как сие в 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???

cyberax@sdmain:~/work/hibernate-3.2$ grep -Ri ibatis *
cyberax@sdmain:~/work/hibernate-3.2$

> То есть мне непонятно почему О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 от межпроцессного общения? Не заметно?
> Не заметно. Запросы к базе всяко больше едят.
А как именно все организовали?

C>

C>for(Customer f : list) s.insert(f);
C>

Так работать не будет так как вставит в 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/&gt;. Просто я в гробу видал все эти
> заморочки и так проблем хватает. Если правильными руками делать, проблем
> не будет с хорошей вероятностью — ставь коммиты близко, делов-то.
Это будет уже игра "повезет — не повезет". А нужно 100% надежность.

> Ладно предлагая мир, все нормально в H. Раньше даже нравилось, но теперь
> он стал как-то не нужен, как впрочем и вся Ява. Но это личное, у кого-то
> оно наверно по-другому...
Ок

Здравствуйте, Cyberax, Вы писали:
C>А как именно все организовали?

Дак вроде бы все просто. Спроси конкретнее...

на стороне java : hibernate + xfire (хотя несколько пожалел, что взял hibernate а не ibatis)
на стороне ruby : собственно RoR + rsoap ну и wsdlToRuby для генерации классов.