Сохранение в SQL Server 2008 с использованием хранимых процедур, JPA и Hibernate

Question

Мы внедряем веб-страницу для поддержания организационной структуры. Структура хранится в SQL Server 2008 и использует новый тип данных HierarchyID. Поскольку у нас были проблемы с воспроизведением JPA и Hibernate с этим новым типом данных, мы решили использовать представления и хранимые процедуры для абстрагирования этого типа данных. Поэтому мы хотим использовать хранимую процедуру для сохранения наших сущностей, но как вы это делаете с JPA, неясно.

Во-первых, применяем ли мы правильный подход, а во-вторых, возможно ли использовать хранимые процедуры для сохранения сущностей, аннотированных JPA?

Answer 1

Мы остановились на подходе, где мы используем собственные запросы для вызова хранимых процедур всякий раз, когда нам нужно обработать тип данных ID иерархии. Это позволило нам избежать использования какого-либо проприетарного SQL, в то же время получая преимущество нового типа данных.

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

Например, для подсчета всех заказов по структуре глубины 'n' регионов, офисов, магазинов и отделов можно использовать что-то вроде следующего:

SELECT COUNT(Orders) FROM Orders WHERE NodeOrderedAt.IsDescendantOf(@Node)

@ ChssPly76 Спасибо за ссылки на две модели. Я буду читать их позже:)

Answer 2

Во-первых, принимаем ли мы правильный подход [...]

Ну, это зависит. Если вы не возражаете против привязки к вашему ядру базы данных, то, я думаю, не совсем неправильно хотеть воспользоваться преимуществами проприетарных функций, таких как HierarchyID. Но вам не нужно использовать новые функции ...

во-вторых, возможно ли использовать хранимые процедуры для сохранения сущностей, аннотированных JPA?

Насколько мне известно, нет . Вы можете вызывать хранимую процедуру, используя «собственные запросы» (см. @NamedNativeQuery и / или EntityManager#createNativeQuery()), но вы не можете использовать их для сохранения сущностей, по крайней мере, с JPA , Если вы не возражаете против использования расширений Hibernate, взгляните на @SQLInsert(callable=true, ...) (см. Главу 2.4.11. Пользовательский SQL для операций CRUD документации по аннотациям Hibernate).

---

Лично мне очень сложно создавать представления, хранимые процедуры и иметь дело с расширениями JPA только для использования HierarchyID. Новые функции - это круто ... когда они упрощают вещи, а не когда они добавляют больше сложности, что является случаем здесь. Другими словами, поскольку использование HierarchyID на самом деле ничего не решает, я бы предпочел придерживаться классического столбца parent_id (и это сделает процесс изменения механизма базы данных более плавным, даже если это очень маловероятно событие).

Answer 3

Вы можете использовать то, что предложил @Pascal, или вы также можете использовать

@org.hibernate.annotations.NamedNativeQuery(
     callable=true,
     name="queryname",
     readOnly=true,
     query="call sproc_name(?,:param)",
     resultSetMapping="your_result_mapping"
)

полный список параметров см. javadoc

Единственная проблема этого подхода заключается в том, что параметр out (если он вам нужен) должен быть первым и должен выводить refcursor.

Также см. this (относится к функциям, но может быть изменено для sprocs). Эти примеры основаны на Oracle, но строка вызова легко модифицируется для MSSQl.

Я не знаю многого из HierarchyId. Можно ли представить его как пользовательский тип Hibernate или какой-либо из типов?