Ант умеет всё, только в нём для этого всего надо писать скрипты и потом поддерживать их. :) Суть мавена в декларативности. Хотя по первому знакомству maven кажется тем ещё говном, типа шаг влево, шаг вправо - растрел. Тонкостей много.

P.S.: если будут вопросы, всегда рад оказаться полезным, мой JID есть в профиле. ;-)

Всем спасибо :) Мы тут наоффтопили конечно, но довольно полезно для меня.

> GWT - ajax web фреймворк

Заменить на Adobe Flex.

> EJB (включая JPA) - у них не получилось с третьего раза )

Тоесть Hibernate вы по-старинке XML-ем описываете без Annotations/Entity Manager?

> Заменить на Adobe Flex.

И ещё ActionScript добавить? Вот в 10 версии обещали мультиязычность, будет Java - можно будет смотреть.

Или заменить GWT на Haxe. Либо лююлй js-фреймфорк.

GWT я бы расшифровал как GovnoWidgetToolkit (Че только не придумают лиш бы программировали только на ихней жабе).

> Тоесть Hibernate вы по-старинке XML-ем описываете без Annotations/Entity Manager?

Как-то я это упустил в том посте, по-моему JPA+Hibernate это Ъ (а EJB только могила исправит). В общем, присоединяюсь к вопросу. :)

ну в JPA нету куче полезностей, которые есть в Hibernate, например lock() или @CollectionOfElements. А то, что JPA суть кастрированное подмножество - лучше его не делает. Ну а аннотации не есть достижение JPA, ибо в хибере они появились задолго до. (Хотя я предпочитаю xml, т.к. в коде иначе слишком много хардкода)

> А то, что JPA суть кастрированное подмножество - лучше его не делает.

Вы таки не знаете, что Hibernate есть реализация JPA? И то что Hibernate использует JPA аннотации и дополняет своими, когда средств JPA недостаточно, тоже не знаете? Кстати над JPA работали разработчики Hibernate. Как итого - нормальный обобщённый интерфейс для всех ORM-ов, который легко расширяется средствами специфичными для любого из этих ORM-ов. ;-)

Не так :). Сначала были аннотации hibernate (хоть они и были якобы JSR), а потом уже было JPA. Более того, еще раз: обобщенное урезанное Г под названием JPA сложно сравнить с полноценным Hibernate, ибо дьявол в деталях. А необходимость "ободщенного" JPA в том виде, в котором его нам дали для меня сомнительна. Лучше подсесть на чистый H чем _так_ себя ограничивать. (правильно тут сравнили SQLite vs Oracle ;) очень похоже)

В любом случае, JPA может быть тем же Hibernate-ом (если использовать его в кач-ве реализации), только его подмножеством; всю работу будет выполнять Hibernate, ну и никто не запрещает использовать специфичные для него вещи.

Я склонен думать, что даже такая стандартизация базовых API ORM-ов есть большой сочный гут. =)

И не надо называть JPA "урезанным Г", это скорее стандартизированный базовый функционал. Кстати, какие ещё ORM реализовали JPA?

> Лучше подсесть на чистый H чем _так_ себя ограничивать

Ещё раз уточню: JPA НИ В КОЕЙ МЕРЕ НИ В ЧЁМ НЕ ОГРАНИЧИВАЕТ!

JPA реализовали еще TopLink и JPOX (из того что счупал)

Ну а на счет "не ограничивает". Вероятно у Вас нет такого оптыта либо везло. Но если есть требование писать в рамках JPA (и не дай бог еще и EJB3), то и вся архитектура будет затачиваться под те возможности, которые есть в JPA. Например те же блокировки, в JPA _нет_ пессимистических блокировок, а в H есть. B итоге мы вынуждены проектировать систему исходя из наличия только оптимистических блокировок, что часто приводит к чудовищному оверхеду, хотя есть вероятность получить scalable решение. И главное таких ньюансов - вагон и маленькая тележка. При том что это в основном проблема ORM в целом, а не именно JPA. Ибо например с ServletAPI или JCP таких больших проблем не возникает. А ORM после написания софта я лично ни разу не менял (да и не думаю что больше 1% в мире тех, кто это делал).

>у maven своя документация очень плохая - читай вот эту книжку. http://www.devzuz.com/web/guest/products/resources#BBWM

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

P.S. А книжка хорошая, надо будет присмотреться.

>у maven своя документация очень плохая - читай вот эту книжку. http://www.devzuz.com/web/guest/products/resources#BBWM

там регистрация постоянно матерится на User ID - если не трудно, выложите куда-нибудь..

>> Что, пишем одновременно под SQLite и Oracle?

>А почему бы и нет?

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

>А где проблемы с производительностью? В первом селекте, где получаются все id?

Проблемы - в том, что сначала выгребается PRIMARY KEY, а потом на КАЖДУЮ СТРОКУ отправляется по отдельному запросу.

Не PREPARED QUERY, не FETCH FORWARD 1 FROM cursorname, а ОТДЕЛЬНЫЙ SQL запрос.

К чему это приводит в *некоторых* СУБД? К тому, что если между двумя подобными SELECT-ами в таблицу был сделан INSERT, кэш результатов инвалидируецо, заново создается план выполнения запроса, и таблица выкачиваиццца заново с диска.

>> Тоесть Hibernate вы по-старинке XML-ем описываете без Annotations/Entity Manager?

>Как-то я это упустил в том посте, по-моему JPA+Hibernate это Ъ (а EJB только могила исправит). В общем, присоединяюсь к вопросу. :)

1) лично я предпочитаю использовать mappings на annotation's
Hibernate позволяет использовать JPA annotations для mappings плюс добавляет много своих.
очень рекомендую прочитать http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#e...

Почему я не рекомендую использовать JPA.
В JPA = урезанный Hibernate
Что урезано (крупные фичи):Criteria API, Кэширование, каскадные операции.
Из мелких фичь - см предидущий link.

2) Вы заблуждаетесь что использоване XML для mappings - это по старинке.
Когда использовать XML, а не annotations:
- Существует необходимость держать несколько mappings на один и тот же класс
- Вы сохраняется класс из чужой библиотеки (не можете поменять исходный код)
- Когда не хватает функциональности аннотаций, кое что можно пока можно описать только через XML
- Когда ваш target jvm не поддерживает java5 (если бы вы знали сколько ещё народу сидит на 1.4)
и т.д.

> Но если есть требование писать в рамках JPA

Есть мнение, что вас ограничивали в большей мере эти самые требования, а не сам JPA. :) Может я и ошибаюсь, печального опыта не имел.

> как в готовой сборке сделать произвольную структуру каталогов

А я разобрался и совсем не жалею, есть неплохие книжки "Better builds with Maven 2" и "Maven user guide".

> Кроме того уже была сделана куча самопальных плагинов к ant'у

В таком случае пришлось писать mojo с аналогичным функционалом для maven. :)

> К чему это приводит в *некоторых* СУБД?

Спасибо, буду иметь ввиду. ;-)

> Когда не хватает функциональности аннотаций, кое что можно пока можно описать только через XML

Вопрос не в тему: атрибут entity-name у <class> это как раз тот случай? Я не нашёл способа сделать это в аннотациях.

> Абстракция, приводящая возможности к самой плохой поддерживаемой СУБД - гафно по определению.

Абстракция абстракцией, а достичь лучшей производительности для каждой конкретной СУБД - задача как раз для Hibernate.

>Он делает так: >select person0_.ID as col_0_0_ from PERSON person0_ >т.е. здесь уже скушали мегабайтов сто памяти. Нифига не скушали. Во всех нормальных БД просто вернется result set, который будет по требованию догружать записи.

>и потом на каждом шагу >select person0_.ID as ID0_0_, person0_.NAME as NAME0_0_ from PERSON >person0_ where person0_.ID=? >т.е. память больше не кушаем, но к базе идёт отдельный запрос на каждый >next итератора. Открыть для себя метод setFetchSize() в запросе.

>Абстракция абстракцией, а достичь лучшей производительности для каждой конкретной СУБД - задача как раз для Hibernate.

Ога, заметно. Вместо того, чтобы открыть курсор (или выгрести данные сразу по условию), мы сначала фетчим по условию праймари кей, а потом - выбираем данные по полученному PK. Офигительно.

Просто нет слов. Если бы так написал в коде очередной похапэ-ньюб, его бы гнобил каждый ЛОР-овец. Когда же так делает великий и могучий Гибернейт - это труЪ.

>>Он делает так: >select person0_.ID as col_0_0_ from PERSON person0_ >>т.е. здесь уже скушали мегабайтов сто памяти.

>Нифига не скушали. Во всех нормальных БД просто вернется result set, который будет по требованию догружать записи.

Ололололо. А на стороне БД, значит, ресурсы не считаны, да? Типа, раз 100 мегов съели не на клиенте, то проблем нет?

>>и потом на каждом шагу >select person0_.ID as ID0_0_, person0_.NAME as NAME0_0_ from PERSON >person0_ where person0_.ID=? т.е. память больше не кушаем, но к базе идёт отдельный запрос на каждый >next итератора.

>Открыть для себя метод setFetchSize() в запросе.

Ога, и во сколько установить эту FetchSize?

Yilativs,

Очень познавательно. А в остальных случаях всё же лучше аннотации? Будущее по Вашему мнению за ними или как? Одни стучат в грудь кулаком, что лучше всё хранить в одном месте, другие - что классы должны быть чистые.

> реализованы лучшие решения из Java EE, в том числе Spring, Hibernate и SiteMesh.

Какой оксюморон! Spring - это Java EE. Не, ну просто можно умереть от смеха!:))

Авторам сего поделия под названием Grails не плохо было бы "Expert One-on-One: J2EE Design and Development" для начала покурить малька, прежде чем так народ смешить. :)

> или выгрести данные сразу по условию

Кстати с этим проблем нет. Это уже другой юзкейз.

> Когда же так делает великий и могучий Гибернейт - это труЪ.

Ну H пытается скрестить две несовместимые парадигмы, реляционную и объектно-ориентированную, отсюда м.б. некоторые потери в производительности. :)

> Когда же так делает великий и могучий Гибернейт - это труЪ.

Правильна! Надо на TrueЪ JDBC все писАть! А лучше - сразу на ассемблере.

Про скорость _разработки_ и надежность кода - так это для жабабыдлокодеров (типа меня), это "не куль"!

> Какой оксюморон! Spring - это Java EE. Не, ну просто можно умереть от смеха!:))

> Авторам сего поделия под названием Grails не плохо было бы "Expert One-on-One: J2EE Design and Development" для начала покурить малька, прежде чем так народ смешить. :)

Ну и? Я читал этот шедевр. А цель Spring: "J2EE Programming should be easy", так чем же Spring не EE? Java EE - это не то, что упаковано в архив, скачиваемый с java.sun.com , а несколько большее. Spring - Java EE и тчк.

Вы таки ему еще про хайберовский кэш второго уровня расскажите.:)

Не хотят люди развиваться. А может и к лучшему. Спецы по Hibernate будут более востребованы и с более высокой зарплатой. :))

Еще раз Spring отдельно. Java EE - отдельно.

Есть матчасть - сановские спеки. Все остальные рассуждения на эту тему - есть суть софистика и схоластика.

Ну сё, я расстроен, Spring - не ынтырпрайз. :)

>Про скорость _разработки_ и надежность кода - так это для жабабыдлокодеров (типа меня), это "не куль"!

Детко, вот расскажи мне, что проще: написать три строчки на java + адын Plain-SQL запрос или ваять ХЗ сколько классов + XML конфигурацию?

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

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

>Вы таки ему еще про хайберовский кэш второго уровня расскажите.:)

Ну, йопт. Ессно, что кэш нужен, раз сама схема изначально допускает такое убогое использование.

>Не хотят люди развиваться. А может и к лучшему. Спецы по Hibernate будут более востребованы и с более высокой зарплатой. :))

Да ради бога. Как прошла мода на XML + XSLT, так и на ORM пройдет. Будете и дальше свою китайскую грамоту вместе с индусами поддерживать.

> три строчки на java + адын Plain-SQL

4.2

Это может в ваших форумах на одной БД достаточно одного запроса, а в большинстве приложений это самое кол-во "три строчки на java + адын Plain-SQL" в конце концов будет превышать по количеству строк кода весь остальной код в этом приложении. А поддерживать этот Plain-SQL-кал окажется некому.

ORM тут вне конкуренции, тупо этого не видеть. ;-)

>Это может в ваших форумах на одной БД достаточно одного запроса, а в большинстве приложений это самое кол-во "три строчки на java + адын Plain-SQL" в конце концов будет превышать по количеству строк кода весь остальной код в этом приложении. А поддерживать этот Plain-SQL-кал окажется некому.

Надо полагать, поддерживать весь быдлокод на ORM, плюс кучу XML-я - проще? Оптимизацию запросов и индексов DBA будет как делать? Видимо, спрашивая "а где это тут у вас такой кривой запрос формируется"?

А доблестные разработчики в ответ будут мычать, что, мол, ХЗ где, и ваще, это ж Гибернейт так все делает, его не люди - боги писали и вообще, что вы к нам с такими вопросами лезете?

То, что тот же Постгрес (про Мускль вообще речь не идет, там все еще хуже) может кардинально менять план выполнения запроса в зависимости от порядка условий во WHERE - это новость, да? Видимо, Гибернейт умеет делать EXPLAIN и на основе этого анализа динамически менять запрос к БД?

Короче, хорошо только на бумаге и на конференциях.

А на деле, хотят фанаты оэрэма или нет, но действительно серьезные системы пишут: а) раз и навсегда под одну БД и б) с ручным составлением запросов, ручной оптимизацией индексов и ручной же настройкой БД.

hibernate annotations vs XML

>Yilativs
Если что, меня Виталий зовут.

>Очень познавательно. А в остальных случаях всё же лучше аннотации?

Есть ещё случаи когда нужен XML.
Например вы делаете коробочное приложение и даете возможность вышим клиентам самим менять mappings под их базу.
Таких случаев довольно много.

>Будущее по Вашему мнению за ними или как?

Существуют ситуации когда аннотациями просто нельзя обойтиись,
ими удобнее пользоваться, но иногда их просто недостаточно, XML mappings никуда не денутся. Просто их будут использовать реже только в тех случаяъ когда это необходимо.

Оба подхода нужны.

XML - гибкость, annotation - удобство.

> Видимо, Гибернейт умеет делать EXPLAIN и на основе этого анализа динамически менять запрос к БД?

Для каждой СУБД там свои HibernateDialect, и запросы динамически формируются под текущий диалект при инициализации приложения или, если надо, в момент запроса.

> но действительно серьезные системы

Ну видимо у всех свой уровень серьёзности, и огромное кол-во проектов на H носят несерьёзный характер. :)

сцуко - рубиевские либы это просто дикий ахтунг какой-то

Hpricot - Xpath нихера не умеет, а на которые не понимает вместо выдачи ахтунга возращает какую-то херню.

webservices - это вообще сплошной дикий ахтунг.

Есть метод возвращает тупой стринг. Вызываю - возвращается результат ~300kb стринг (экранированный XML). Судя по отладке - время вызова доли секунды (успевает на клонсоль результат вывести). Возврат из метода 20 секунд. Какого хера он делает 20 секунд на AMD5200x2 когда вызов мгновенный? Одну единственную строку делает?

Сериализация вообще песня. XSD::Mapping.obj2xml - шикарно кормим дерево получаем строку с xml. XSD::Mapping.xml2obj - результат хрень из SOAP::Mapping::Object. Если вообще десериализуется. Ахренеть.

Это млять стандартные библиотеки? Каво там руби вытеснить должен?

>> Видимо, Гибернейт умеет делать EXPLAIN и на основе этого анализа динамически менять запрос к БД?

>Для каждой СУБД там свои HibernateDialect, и запросы динамически формируются под текущий диалект при инициализации приложения или, если надо, в момент запроса.

Отлично. Эти запросы формируются с учетом плана исполнения на *конкретной* струетуре таблиц в БД? Или они формируются исходя из того, как это посчитали нужным боги-разработчики гибернейта?

Был здесь один любитель ОРМ, все никак не мог понять, чего это система делала seq.scan по PRIMARY KEY.

Брось каку.

Повторюсь, вообще-то 2007 год был годом, когда официально забили последний гвоздь в ROR и весь хайп, поднятый вокруг Ruby. 2008 год это год Groovy и Scala. Кто победит неизвестно. Предпочтения все отдают Scala

>Брось каку.

Всенепременно. Как проект доделаю так и сразу. Если после первой альфы не перепишу все нахрен. Скала выглядит серьезным претендентом.

ActiveRecord вышел, когда Хибер был уже в 3-й версии

если не секрет, а почему не java?

нам бес сомнения нужны приключения? ;-)

>> GWT - ajax web фреймворк
>Заменить на Adobe Flex.

Почему?


if (WindowsUser)
why not MS Silver Light?

> нам бес сомнения нужны приключения? ;-)

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

> Отлично. Эти запросы формируются с учётом плана исполнения на *конкретной* структуре таблиц в БД? Или они формируются исходя из того, как это посчитали нужным боги-разработчики гибернейта?

И то, и другое, в меру возможностей. :)

>Если после первой альфы не перепишу все нахрен. Скала выглядит серьезным претендентом.

А что тебе понравилось/не понравилось Scala?