Hibernate

[Flying Hen]

Кто-нибудь работал с этой вещью? Как впечатления?
http://www.hibernate.org/

Working with object-oriented software and a relational database can be cumbersome and time consuming in todays
enterprise environments. Hibernate is an object/relational mapping tool for Java environments. The term
object/relational mapping (ORM) refers to the technique of mapping a data representation from an object model
to a relational, SQL-based structure.
Hibernate not only takes care of the mapping from Java classes to database tables, but also provides data query
and retrieval facilities and can significantly reduce development time otherwise spent with manual data handling
in SQL and JDBC. Hibernates goal is to relieve the developer from 95 percent of common data persistence
related programming tasks.

[Brat]

Коллега на прошлой неделе ковырял. Приделал к MySQL. Что-то у него не до конца заработало, но отзывался очень восторженно.

[faw]

не с такой - но идея таже Toplink от ,Оракл (те на самом деле как обычно не Оракл, но они их купили)

про топлинк
Удобно и быстро слабать DAO layer
но для сложных запросов все таки полегче обычный SQL чем его язык запросов.
Из плюсов - не надо самому заполнять объекты из рекордсета, не надо писать всякоразные апдейты, не надо самому делать кэширование

Из минусов - сложные запросы тяжело читаемы в их языке запросов (надо очень сильно привыкать)
Памяти жрет - ну просто ОЙ. Надо очень аккуратно следить за тем что кэшируем
Если больше чем одна jvm - надо запускать синхронизатор - тоже ресурсоемкая штука.

[Masterok]

Пойдите на www.theserverside.com и задайте поиск на hibernate vs JDO. У них там достаточно шумные дискуссии по этому поводу. Например эта: http://www.theserverside.com/news/threa ... 9732#85428

Вкратце:
1. hibernate rulezz, free, but not a standard
2. JDO 1.0 is a standard, but not quite satisfactory, majority of JDO implementations suck or not free (KODO $3000)
3. next version of JDO standard is promising to be better, all the more the creator of Hibernate Gavin King is included into the JDO standard development committee
(sorry for English, дольше было бы переводить)

Я сейчас сам в ожидании следующей версии JDO, разработанной под влиянием hibernate и Гавина Кинга. Hibernate API тоже, скорее всего изменится в сторону JDO в силу взаимовлияния.

По поводу Toplink. Кстати, изначально он не от Оракла, Оракл его купил годика полтора назад. На этой неделе мне довелось поговорить с Toplink product manager from Oracle. На мой вопрос по поводу JDO он ответил, что как только выйдет новая удовлетворительная спецификацияJDO они тот час же будут менять свой API в его сторону.

Практический совет - подождать выхода новой версии JDO. Это стандарт - за ним будущее. Но если нужно срочно - используйте hibernate or Toplink, оба отличные продукты. Но с прицелом, что потом придется много переделывать.

[Masterok]

Еще о hibernate. Гавин Кинг, его создатель поступил на постоянную работу в JBoss. Наиболее пессимистичная часть сообщества theserverside.com объявила, что все, теперь хана: в скором времени для того, чтобы установить hibernate, надо будет установить и сам JBoss, что приведет к гибели hibernate как независимого open source free product.

[testuser]

не с такой - но идея таже Toplink от ,Оракл (те на самом деле как обычно не Оракл, но они их купили)

про топлинк
Удобно и быстро слабать DAO layer
но для сложных запросов все таки полегче обычный SQL чем его язык запросов.
Из плюсов - не надо самому заполнять объекты из рекордсета, не надо писать всякоразные апдейты, не надо самому делать кэширование

Из минусов - сложные запросы тяжело читаемы в их языке запросов (надо очень сильно привыкать)
Памяти жрет - ну просто ОЙ. Надо очень аккуратно следить за тем что кэшируем
Если больше чем одна jvm - надо запускать синхронизатор - тоже ресурсоемкая штука.

Согласен со всем (насчет Топлинка). Хочу еще добавить - часто тяжело а то и просто невозможно составить некоторые сложные запросы. Запросы при этом выходят отнюдь не оптимальными, всегда нужно думать о низлежащей базе данных, абстрагироваться до уровня объектов не получается.
Запросы составлять не очень просто.
Если структура базы данных часто меняется, нужно затрачивать много усилий на переделку всего, не только запросы нужно переделать, но и вспомогательные классы с помощью их программы.

В общем наша контора решила отказаться из-за того что медленно работает и медленней разрабатывается.

[Chelya]

Отличная вешь именно для object-relational mapping. Все что выходит за пределы данного концепта надо делать ручками (sql/jdbc).
Согласен с Masterok - если надо сейчас, то Hibernate решает все проблемы, причем бесплатно. Если на потом и есть даньги на commercial product, то лучше сразу JDO.
Что JDO, что Hibernate, если нет опыта работы с подобными библиотечками, то займет какое-то время врубиться в идею. Хорошие open source implementations JDO на данный момент отсутствуют.
Если есть сомнения по поводу поддержки - я получал ответы на форуме в течении 20 минут посреди ночи.

Кстати, не у кого нет случаем 4 и 5 главы "Hibernate in Action"? Я как-то проворонил их на tss.

[faw]

Согласен со всем (насчет Топлинка). Хочу еще добавить - часто тяжело а то и просто невозможно составить некоторые сложные запросы. Запросы при этом выходят отнюдь не оптимальными, всегда нужно думать о низлежащей базе данных, абстрагироваться до уровня объектов не получается.
Запросы составлять не очень просто.
Если структура базы данных часто меняется, нужно затрачивать много усилий на переделку всего, не только запросы нужно переделать, но и вспомогательные классы с помощью их программы.

В общем наша контора решила отказаться из-за того что медленно работает и медленней разрабатывается.

Ну мы пошли по такому пути
используем только для простейших запросов - для сложных - либо мапили к view либо использовали просто executeSelectCall
переделывать можно и без их программы - там в принципе конфиг файл простой (а можно еще вместо конфига сделать java source - тогда еще легче) Мы именно так делаем - получается быстро.

[hooch]

Согласен со всем (насчет Топлинка). Хочу еще добавить - часто тяжело а то и просто невозможно составить некоторые сложные запросы. Запросы при этом выходят отнюдь не оптимальными, всегда нужно думать о низлежащей базе данных, абстрагироваться до уровня объектов не получается.
Запросы составлять не очень просто.
Если структура базы данных часто меняется, нужно затрачивать много усилий на переделку всего, не только запросы нужно переделать, но и вспомогательные классы с помощью их программы.

В общем наша контора решила отказаться из-за того что медленно работает и медленней разрабатывается.

Имел подобный негативный опыт с Топлинк в одном крупном банке, slow as hell, пришлось просто отказаться от него.

[Palych]

Ya vsegda govoril chto Mapping dolzhen byt' Object-Relational, not Class-Relational.

[Chelya]

Ya vsegda govoril chto Mapping dolzhen byt' Object-Relational, not Class-Relational.

Palych, для тех кто в лесу: что имеется в виду?

[Palych]

Ya vsegda govoril chto Mapping dolzhen byt' Object-Relational, not Class-Relational.

Palych, для тех кто в лесу: что имеется в виду?

Sorry, prosmotrel vopros.
Esli korotko - naibolee udobnymi perenoschikami dannyh mne kazhutsya DOM documents. Osobenno Dom4J, poskol'ku tam XPath vstroen v Node.
Pri etom struktura dokumenta dolzhna opredelyat'sya zaprosom, a ne dannymi kotorye zaprashivayutsya.

[Chelya]

Ya vsegda govoril chto Mapping dolzhen byt' Object-Relational, not Class-Relational.

Palych, для тех кто в лесу: что имеется в виду?

Сорры, просмотрел вопрос.
Если коротко - наиболее удобными перенощиками данных мне кажутся ДОМ доцументс. Особенно Дом4Й, поскольку там ХПатх встроен в Ноде.
При етом структура документа должна определяться запросом, а не данными которые запрашиваются.

Тогда это просто Object database не имеюшее отношения k Whatever-Relational. Всё равно не врубил про Object-Relational vs Class-Relational.

[Palych]

Ya vsegda govoril chto Mapping dolzhen byt' Object-Relational, not Class-Relational.

Palych, для тех кто в лесу: что имеется в виду?

Сорры, просмотрел вопрос.
Если коротко - наиболее удобными перенощиками данных мне кажутся ДОМ доцументс. Особенно Дом4Й, поскольку там ХПатх встроен в Ноде.
При етом структура документа должна определяться запросом, а не данными которые запрашиваются.

Тогда это просто Object database не имеюшее отношения k Whatever-Relational. Всё равно не врубил про Object-Relational vs Class-Relational.

Я говорю про маппинг.
Все мы с детства знаем что данные лучше хранить в релационных базах, а передавать и показывать удобнее обьекты.
Отсюда зародилста маппинг.
Обычно под ним подразумневают создание специальной иерархии классов, повторяющих структуру таблиц (Domain Data Transfer Objects) или конкретных запросов (other DTOs).
Вот и полужается что данные мапятся в классы.
Такая шема хорошо выглядит когда смотриш на диаграммы и расщитываеш некие сферические запросы в вакууме.
По другую сторону екстрима находится применение разного рода коллекций обьектов (Maps, RecordSets, etc.) Они обычно быстрее, но менее удобны на клиенте, когда нужно достать конкретную ячейку данных.
Вот я и думаю что лучшее решение режит посерединее - в структуре которая достаточно гибка в конструировании, и в то же время поддерживает сложные древовидные данные. А наличие механизма "вторичного" поиска и сортировки делает ее еще более привлекательной.

[Chelya]

Теперь понял - спасибо.

Я говорю про маппинг.
Все мы с детства знаем что данные лучше хранить в релационных базах, а передавать и показывать удобнее обьекты.

Ну, некоторые все же с юности

Отсюда зародилста маппинг.
Обычно под ним подразумневают создание специальной иерархии классов, повторяющих структуру таблиц (Domain Data Transfer Objects) или конкретных запросов (other DTOs).
Вот и полужается что данные мапятся в классы.
Такая шема хорошо выглядит когда смотриш на диаграммы и расщитываеш некие сферические запросы в вакууме.
По другую сторону екстрима находится применение разного рода коллекций обьектов (Maps, RecordSets, etc.) Они обычно быстрее, но менее удобны на клиенте, когда нужно достать конкретную ячейку данных.
Вот я и думаю что лучшее решение режит посерединее - в структуре которая достаточно гибка в конструировании, и в то же время поддерживает сложные древовидные данные. А наличие механизма "вторичного" поиска и сортировки делает ее еще более привлекательной.

Как теоретическая идея звучит интересно. Но я себе слабо представляю что-то подобное в реальности. Для таких вешей и сушествуют object databases. А конвертирование relational database в object database on the fly вряд ли возможно.

[Palych]

Как теоретическая идея звучит интересно. Но я себе слабо представляю что-то подобное в реальности. Для таких вешей и сушествуют object databases. А конвертирование relational database в object database on the fly вряд ли возможно.

Где-то год назад, усугубив водкой, я даже набросал прототип такой штуки.
Завтра пойду куплю памяти для писюка, откопаю, причешу и куда-нибудь в публичное место выложу. Для увеличения количества Добра на планете....
Что-то мне опять захотелись величия... Где моя треуголка?...

[Chelya]

Как теоретическая идея звучит интересно. Но я себе слабо представляю что-то подобное в реальности. Для таких вешей и сушествуют object databases. А конвертирование relational database в object database on the fly вряд ли возможно.

Где-то год назад, усугубив водкой, я даже набросал прототип такой штуки.
Завтра пойду куплю памяти для писюка, откопаю, причешу и куда-нибудь в публичное место выложу. Для увеличения количества Добра на планете....
Что-то мне опять захотелись величия... Где моя треуголка?...

А почему гениальное творение пылится и не используется? Код в студию!

[m_kaspar]

еще одна

шумная дискуссия

http://saloon.javaranch.com/cgi-bin/ubb ... 8&t=000011