Вопрос по поводу Java Persistence и хранимых процедур. Просматривая спецификацию JSR-317 JPA 2.0 не нашел ничего о хранимых процедурах. В Hibernate таковое средство имеется, а в JPA 2.0 выходит - нет?
Кто работает с Java Persistence расскажите в двух словах, как решаете эту проблему. Конечно можно использовать JDBC вызовы напрямую, но это как-то нехорошо.

Похоже я не прав. Некоторое пренебрежение хранимыми процедурами со стороны JPA и Hibernate связано с природой контекста постоянства. И видимо в использовании JDBC напрямую для их вызова ничего криминального нет.

В Hibernate поддержка  хранимых процедур есть. Вы так же можете ее использовать и из JPA, если используете его в паре с Hibernate, насчет других ORM не знаю.

Бегло погуглив:
В EclipseLink (если я не ошибаюсь - это наследник Oracle toplink essentials) тоже есть поддержка хранимых процедур: http://wiki.eclipse.org/EclipseLink/Examples/JPA/ORMQueries

Тут нужно помнить только о том, что обход хайбернайта или JPA может вызвать рассинхронизацию данных в базе и памяти, и принимать соответствующие меры.

Вы правы, все это так. Однако:
1. В JPA, сколь я понял, нет средств для вызова хранимых процедур. Интересно, разработчики JPA намеренно игнорируют эту проблему?
2. В NATIVE Hibernate для этого создается псевдозапрос, что тоже похоже на "отмазку" .
3. Для Oracle имеет существенное значение возможность вызова хранимых процедур, так как есть задачи, которые без этого выполняются либо сложно либо неэффективно. Как мы знаем есть системы, где огромное количество задач выполняется в ХП. В связи с этим у меня вопрос и возник. 

Да, ХП просто игнорируются. Если вам нужны хранимые процедуры, то скорее всего и пакет надо выбрать другой iBatis, jdbcpersistence, etc.

JPA и Hibernate не предназначены для работы с хранимками. и все очень просто объясняеться - у вас фактически нет БД. 
Вы ведь можете сторить данные не только в БД. как быть если вы будете сторить данне просто в XML. там уж точно нет хранимок.

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

to hamsterKSU

То что вы написали, это некоторый идеальный взгляд на простое приложение.

1. В случаях, когда структура базы данных сложна и приложение тяжело нагружено, приходится использовать специфику базы для повышения производительности.

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

3. Представьте себе базу с терабайтами данных, когда требуется периодически и эффективно выполнять весьма специфические задачи над массой данных. Отказываться в таком случае от использования хранимых процедур просто безобразие.

4. Другое дело, что результаты работы хранимых процедур как правило не должны попадать в контекст постоянства, а значит они слабо связаны с основным назначением ORM. Хотя я полагаю разработчики JPA не правы, что упускают ХП из виду вовсе.

Так JPA и Hibernate и придуманы для упрощения программирования простых приложений.

Уточните, пожалуйста вашу позицию. Из вашего высказывания вытекает, что для сложных приложений JPA и Hibernate не подходят?
А как же попытки SUN усиленно пропихивать гибрид  EJB и  JPA как последнее слово науки и техники.
Писать все на JDBC?
Я тут начал "ваять" свою универсальную реализацию DAO и понял, что пытаюсь состряпать что-то похожее на Hibernate, только более убогое (хотя и более эффективное в силу малости уровня надстройки).  Извечный вопрос назрел - "Что делать"?

Думаю, что действительно иногда легче написать на JDBC,  в других случаях есть iBatis и др. 

Меня не один пакет не устроил, и я написал своё (смотри подпись)

С Хайбернэйтом я намучался много, и никогда больше к нему не притронусь по собственному желанию. Как, вероятно и к JPA, если только как реализатор JPA.

Не смотря на кажущуюся простоту и удобство Хайбернэйт и JPA, я думаю, что принципы и возможности заложенные в неверны. Например 
- кэширование (в каждой конкретной ситуации кэширование нужно разное, глубокое иногда, иногда - нет). По моему глубокому убеждению, кэшировние принадлежит к другому архитектурному слою.
- поздний сброс объектов в базу данных. В большинстве случаев это запутывает. Сброс должен быть тогда, когда в коде прописано save (store, saveOrUpdate, etc.) а не тогда когда, хайбернайт решит: -пора. 
- время требуемое на старт аппликухи - хайбернэйт сильно заменяет start-up.

В общем, при кажущейся полезности, Хайбернэйт не тот пакет, который мне помог работать быстрее и эффективнее, скорее наоборот. А начал я с ним работать, по тем-же причинам что и остальные его  пользователи: как-же так, уже готовое решение, зачем-же писать своё. С тех пор мои позиции поменялись и когда я вижу пакет, который либо обещает слишком много, либо тянет за собой такое количество библиотек, что суммарный объём jarов становиться больше объема самого сервака, я такой пакет не использую. Хайбернэйт попадает под оба этих описания. 

С другой стороны, я не был достаточно усерден в изучении Хайбернэйта, я как посмотрел на его старт-ап тайм сразу понял - дерьмо пакет.

Авторы успешных фреймворков всегда начинали с простой и понятной идеи, чтобы потом, желая понравиться всем, превратить свое детище в монстра. Идея ORM, как следует из названия, в маппинге. Это упрощение программирования и сопровождения (однако, по моим наблюдениям, постоянно на форумах обсуждают, как победить lazy initialization. Как же так? Это же бонус от любезных авторов. Они же возомнили, что это must have.). 

Производительность в ORM - не самоцель. Для решения проблем производительности (и других "кошмаров", перечисленных mbasil ) наверное доступны другие средства. Конечно, никто не отменял JDBC (как и наличие RMI не похоронило программирование сокетов). Но в этом случае идея "одна сущность - одно хранилище" как бы размывается. На мой взгляд, hamsterKSU привел удачный аргумент, что хранилище не обязательно должно быть базой данных - авторы JPA стиль соблюли. И сама идея такого упрощения - жизненная.  Это идея разбивать, приводить сложное к набору более простых вещей. Иными словами, наверное архитектуру приложения надо приспосабливать к идее ORM. А не наоборот. 

Всё верно, надо подстраивать архитектуру под JPA, коль уж используешь JPA или хайбернэйт... И забыть, что у за хайбернэйтом стоит база данных. Думаю, что архитекторы разобьются на две группы. На тех, кто начал программирование с пор когда о Хайбернэйт и JPA не слышали, что позволило им набить руку и в подробностях изучить базы данных, и тех, кто пришёл в программирование чуть позже или кому не нужно было работать с базами до недавнего времени.

Попадая в первую группу я не могу забыть базы данных полностью абстрагироваться от них. Поэтому воспринимаю хайбернэйт как лишний слой. Ещё раз повторюсь, не ОРМ, а именно Хайбернэйт или JPA – уж слишком много они пытаются сделать. На мой взгляд, надо было остановиться на той модели которую представляет собой iBatis –то есть чистый ORM. Без кэширования, без позднего слива в бд, без lazy loading и прочих 'удобств' чаще оборачивающихся потерей времени чем сбережением оного.

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

1.    Время загрузки приложения действительно увеличивается, видимо потому, что Hibernate в момент загрузки генерирует SQL предложения.  Увеличение времени загрузки не такое, чтобы копья ломать, да и стартуем продукционное Java EE приложение не каждый день.
2.    То, что предполагается – хранилище может быть любым – в идеале выглядит замечательно хорошо! Уже лет пятнадцать пишут, что скоро объектные базы похоронят реляционные и ORM в принципе не понадобится. А воз и ныне там. Однако, чу! Что в аббревиатуре ORM означает буква R? XML базы и проч. пока игрушки для эпатажа. Жертвовать производительностью ради идеи получения эфемерной выгоды от будущего универсального доступа совершенно бессмысленно.
3.    Отличное замечание dobrolub по поводу двух типов разработчиков мне тоже не раз приходило в голову. Сам я тоже принадлежу к первому типу, так как с 85 года занимаюсь базами данных. И даже на примере курсов SUN видно, как жертвуют качеством разработчики второго типа только потому, что работают с базой данных, как с «черным ящиком». В связи с этим можно еще поругать Hibernate, например за то, что применение диалекта Oracle  не гарантирует вам, что SQL предложения будут действительно и точно настроены под Oracle. 
4.    В защиту Hibernate наверное стоит сказать, что "lazy loading" не сложно отменить. Они попытались сделать контекст постоянства кэшем первого уровня, которым можно было бы "тонко" управлять. Однако, чтобы "тонко" управлять, надо знать "тонкости" этого кэша, что на самом деле задача не простая. Предоставление возможности управления отношениями между сущностями снимает с разработчика необходимость эти связи обеспечивать с помощью собственного программирования, но приводит к необходимости разбираться в настройках.
5.    В общем, куда не кинь всюду клин. Все же легче разобраться с настройками, чем писать свою реализацию ORM, хотя мы можем. Даже если мы напишем эту свою, самую лучшую реализацию, как потом в ней будут разбираться те, кто придут после нас? Я знавал команду, которая написала для себя свой собственный специфический (и ужасно эффективный) сервер приложений . . .
6.    Придется видимо сдаваться на милость победителя (то есть JPA суть Hibernate) – стандарт, как ни как.

Ну есть ещё open-jpa (apache)... 

Я думаю что в JPA и Hibernate не встроена поддержка ХП чисто из-за _переносимости_ приложения!!!!  Если мы вставляем бизнес логику в ХП например Оракла, то для реализации на MySQL придется все хранимые процедуры переписывать!!!! А это не ГУД!
Проще всего создать пакеты "бла-бла-бла.sp" и "бла-бла-бла.function"  и держать там реализацию бизнес-логики написанную с использованием технологий JPA или Hibernate (или прочих). Только в этом случае приложение может иметь различные источники хранения данных.

P.S.:
И ещё. Для тех кому нужно перелапачивать в конце дня какие-то массивы данных, то нужно понимать что для таких задач нужно использовать спец средства которые занимаются именно этой задачей. Например Oracle Financial Analyzer. Или приложения которые лепят кубы и их срезы. Для каждой БД должны быть свои средства, если нет то нужно их написать или заказать. А из простого приложения формировать какие-то сложные расчеты это IMHO не правильно. Максимум что должно уметь приложение, это формировать _простые_ печатные формы и то не факт, не даром выпускают всякие там Crystal Report'ы.

Это сообщение отредактировал(а) javastic - 10.10.2011, 13:06

Нет. Это описания ниши использования JPA



Разработчики JPA думали об этом, это ломает их концепцию.



Да, гонять. В противном случае ломается концепция JPA.



Разработчики JPA думали об этом, это ломает их концепцию.



Именно. В JPA возникнет множество сложностей реализации.



Со своей точки зрения они правы. Они разработали инструмент под определенную нишу. Вы пытаетесь его втиснуть туда, где он совершенно не работает.

P.S. Представьте себе топор. У него удобная ручка чтобы рубить. А Вы его решили зазубрить и пилить им. И жалуетесь на разработчиков топора, которые не подумали о прикреплении удобной ручки с торца топорища.

Добавлено через 2 минуты и 4 секунды

Увы, с наличием сотен миллионов строк и необходимостью с ними работать Вы ничего не сделаете. Это данность. И ни один ORM тут не поможет.

Добавлено через 5 минут и 7 секунд

Эта задача решения не имеет. Для обеспечения максимальной производительности необходимо в каждом запросе вычитывать только те поля, которые нужны здесь и сейчас. Т.е. lazy loading необходимо регулировать для каждого поля объекта в каждом запросе. Это недостижимо и совершенно не укладывается в концепцию легкой работы с объектами.

Кратко, EclipseLink как провайдер поддерживает вызов хранимых процедур: http://en.wikibooks.org/wiki/Java_Persiste...ored_Procedures

Что касается архитектуры. Думаю, если следить за дизайном, то не должно быть проблем переписать узкие места в контроллерах, вызвав где надо хранимую процедуру либо выполнив native query.