Я думаю что в 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.