0

I am using hibernate and spring mvc and using annotations .. I want that no parent entity should get deleted if children exists. Now I can do it explicitly by code , but can it be done directly via hibernate , I mean by configuration??

Secondly, In spring I am getting sessionFactory as and when (In every dao). To get session I use

sessionFactory.getCurrentSession()

should I get session/sessionFactory in a singeleton class and use it every where??

and I am using

sessionFactory.getCurrentSession().save(batch);

sessionFactory.getCurrentSession().delete(batch);

then I don't need to bother about closing and starting session, as it is done automatically. Is am correct?

Community
  • 1
  • 1
ManMohan Vyas
  • 4,004
  • 4
  • 27
  • 40

1 Answers1

2

  1. That is guaranteed by the foreign key constraints that you should have in the database. If the child has a foreign key to its parent, and you try to delete the parent, the database will refuse the deletion and you'll get an exception.

  2. Yes, Spring opens a session for you and associates it to the current transaction, and closes it automatically when the transaction ends. You shouldn't care about opening and closing sessions. Inject the session factory into your DAOs, and get the current session from this factory each time you need it.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • what about adding such constraint in hibernate, I know that can be managed by db level constraints, but I suppose ORM Exceptions are heavy for performance issues, is am correct?? and is there a way out to mange it via configurations generically. Otherwise I need to add different check for dependents before deleting each entity. – ManMohan Vyas Mar 11 '13 at 06:11
  • Hibernate doesn't check constraints. The database does. It's the only reliable place to check them. You can add constraints annotations in the model to have Hibernate generate them in the database schema (if you use schema generation). You should worry about correctness first, and then about performance. – JB Nizet Mar 11 '13 at 08:17
  • OK aggred, so if I add all these constraints, what is the better way of implemention among two : 1) I shouldn't bother about cnstraints as they are there in db and directly go and call delete , it will fail I can catch that and show message that some dependency exists, 2) Even if db level constraints are there I explicitly check it via code and show error accordingly ... which way is the preferred way ? If second one is the prefered way, then I should believe that there is no generic way supported to check such dependecy constraints(my original question) ... – ManMohan Vyas Mar 11 '13 at 09:33
  • It's hard to give a meaningful error message using the first option, because the exception won't provide an easy and portable way to know which constraint has caused the exception. So if you want clear error messages, go with the second option. But you'll need to execute queries. There's no generic way to check. And even if you don't find any child reference, the delete might still fail if another concurrent transaction has inserted a child between the check and the delete. – JB Nizet Mar 11 '13 at 09:41