-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 8 posts ] 
Author Message
 Post subject: Delete using hql with cascade="all-delete-orphan"
PostPosted: Wed Jul 06, 2005 1:20 am 
Newbie

Joined: Tue Jul 20, 2004 4:35 am
Posts: 7
Hibernate version: 3.0

Just a simple question. I'd like to delete a parent entity together with its child records. The cascade property in the entity hbm file is set to "all-delete-orphan".

When I use
session.delete(session.load(entity.getClass(), entity.getId()));
everything works fine and child records are deleted.

But my motivation is to be able to delete the whole thing without loading the entity. The following code
session.createQuery("delete Entity where id = 1").executeUpdate();
throws a "child record found" exception.

What can the problem be? Please your advice. Thanks a lot in advance.
L G


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 4:00 am 
Newbie

Joined: Tue Jul 20, 2004 4:35 am
Posts: 7
We moved to v3.1 and the problem remains. Or am I missing smth here?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 4:40 am 
Regular
Regular

Joined: Sat Nov 05, 2005 5:33 am
Posts: 70
Location: Linz, Austria
IMHO, you're bypassing Hibernate by using a delete query. This way, you're on your own.

If you want Hibernate to take care of the relationships, I don't think you've got any way around loading the objects. But you probably don't have to load the objects in the collection as well, I think, the proxies will do just fine.

_________________
hth,
Heinz
Don't forget to rate if this helped


Top
 Profile  
 
 Post subject: Re: Delete using hql with cascade="all-delete-orphan&qu
PostPosted: Tue Nov 15, 2005 10:29 am 
Expert
Expert

Joined: Fri Aug 19, 2005 2:11 pm
Posts: 628
Location: Cincinnati
levg wrote:
Hibernate version: 3.0

Just a simple question. I'd like to delete a parent entity together with its child records. The cascade property in the entity hbm file is set to "all-delete-orphan".

When I use
session.delete(session.load(entity.getClass(), entity.getId()));
everything works fine and child records are deleted.

But my motivation is to be able to delete the whole thing without loading the entity. The following code
session.createQuery("delete Entity where id = 1").executeUpdate();
throws a "child record found" exception.

What can the problem be? Please your advice. Thanks a lot in advance.
L G


In hibernate3 the team decided to follow the ejb3 spec and change the function of session.delete around entirely. It will only delete the object and all its children if EVERYTHING about an entity and its children is already loaded into memory from the database. This is to avoid performance problems involved with what you explained, loading everything into memory to then just delete it all.

The best way to do it now (performance wise) is to run
Code:
session.update("delete...").executeUpdate()

queries with some custom written hql delete queries.

_________________
Chris

If you were at work doing this voluntarily, imagine what you'd want to see to answer a question.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 11:31 am 
Beginner
Beginner

Joined: Tue Jun 07, 2005 11:36 pm
Posts: 22
I wouldn't worry too much about loading the entity and then calling delete on it. If you have most of your properties and associations set to load lazy and/or by proxy, the processing hit should be minimal. If you turn on debug logging for the org.hibernate.sql package (at least, possibly more if you want), you should be able to see how much is actually getting loaded prior to the delete statement. You can tune your lazy/proxy settings from there.

Otherwise, multiple HQL statements will work, but you aren't taking advantage of the cascade settings then.

e

_________________
Useful? Hit me with a point! Completely off base? Ya, well, what do you expect from a newbie...


Top
 Profile  
 
 Post subject: Re: Delete using hql with cascade="all-delete-orphan&am
PostPosted: Tue Nov 15, 2005 12:14 pm 
Newbie

Joined: Tue Jul 20, 2004 4:35 am
Posts: 7
kochcp wrote:
In hibernate3 the team decided to follow the ejb3 spec and change the function of session.delete around entirely. It will only delete the object and all its children if EVERYTHING about an entity and its children is already loaded into memory from the database. This is to avoid performance problems involved with what you explained, loading everything into memory to then just delete it all.

The best way to do it now (performance wise) is to run
Code:
session.update("delete...").executeUpdate()

queries with some custom written hql delete queries.


Hi,

Thanks for the answer.

But... session.update(String hql) - there is no such API...


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 12:43 pm 
Expert
Expert

Joined: Fri Aug 19, 2005 2:11 pm
Posts: 628
Location: Cincinnati
you might like this upcomming feature
http://opensource2.atlassian.com/projec ... se/HHH-695

oh, and session.createQuery("delete ...").executeUpdate() is what i meant to type instead of session.update("delete... ).executeUpdate()

_________________
Chris

If you were at work doing this voluntarily, imagine what you'd want to see to answer a question.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 16, 2005 2:19 am 
Newbie

Joined: Tue Jul 20, 2004 4:35 am
Posts: 7
Great, thanks


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 8 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.