- This topic has 2 replies, 3 voices, and was last updated 19 years, 11 months ago by
.
-
Posts
-
First:
What do you recommend as an approach to working one-to-many mappings (and other unsupported mappings) for the short term for hibernate. I know I am going to lose my mappings when the new support comes, but I can’t wait. Is there any guideline about how to retrofit my work so that when the support is there I will be able to take advantage of it.Second:
I have been reading Hibernate In Action by Hibernate authors. They have several recommendations for something called HibernateUtil (which roughly corresponds to the HibernateSessionFactory in ME) There are several topics that seem important in their implementation that are not addressed by the ME approach.
They choose to have 2 threadlocals (1 for sessions, 1 for transactions) and they seem to have a good reason for it.
They use an InfrastructureException (extends RuntimeExeception) to wrap HibernateExceptions.
They put the beginTransaction calls in there and use the existing Transaction if it exists.
They use a filter to commit transactions.What do you think?
#1: We have not mapped out any migration path(s) yet since the requirements are not complete yet.
#2: Good ideas – I will take a look at Hib in Action stuff. For now, there should be nothing stopping you from subclassing (or directly modifying) the HibernateSessionFactory class that ME generates to add the ThreadLocal for transactions. As for InfrastructureException – this is a contentious one, battle between folks who prefer that all exceptions be RuntimeExceptions, and those who think using caught exceptions is ok. I do not think we want to get into this battle – if you want, you can write a delegate class to transform exceptions thrown by calls to the session factory class to RTExceptions.
I prefer the way Spring Framework does their Hibernate integration – concepts of DAOSupport, injection of a session, and using templates to perform persistence operations (you do not do the begin/commit/rollback/close calls, just provide the innards). We will see which approach seems more sensible as we progress with requirements definition.
