Firstly, are we taking the correct approach [...]
Well, it depends. If you don't mind being tied to you database engine then I guess it's not totally wrong to want to benefit from proprietary features like HierarchyID
. But you don't have to use new features...
secondly, is it possible to use stored procedures to persist entities annotated with JPA?
To my knowledge, no. You can call stored procedure using "native queries" (see @NamedNativeQuery
and/or EntityManager#createNativeQuery()
) but you can't use them to persist entities, at least not with JPA. If you don't mind using Hibernate extensions, have a look at @SQLInsert(callable=true, ...)
(see chapter 2.4.11. Custom SQL for CRUD operations of Hibernate Annotations documentation).
Personally, I find it very cumbersome to create views, stored procedures and to deal with JPA extensions just to use HierarchyID
. New features are cool... when they do simplify things, not when they add more complexity which is the case here. In other words, because using HierarchyID
doesn't really solve anything, I think I'd rather stick with a classic parent_id
column (and this will make the process of changing the database engine smoother even if this is a very unlikely event).