Why does Hibernate check not-null Properties on delete

AHennig · **Joined:** Mon Mar 01, 2004 5:35 am **Posts:** 1

When I want to delete an objekt from database hibernate throws an error when properties are null, but defined not-null in the mapping-document.
Hibernate-Version: 2.1.2
Stack-Trace:
net.sf.hibernate.PropertyValueException: not-null property references a null or transient value: de.advitec.bean.name
at net.sf.hibernate.impl.SessionImpl.checkNullability(SessionImpl.java:1248)
at net.sf.hibernate.impl.SessionImpl.doDelete(SessionImpl.java:1216)
at net.sf.hibernate.impl.SessionImpl.delete(SessionImpl.java:1146)

This had worked fine in version 2.0.3.
Normally I just want to delete the object by ID.

Thanks Andreas

michael · **Posted:** Mon Mar 01, 2004 6:05 am

The fastest way to delete by id is session.delete(session.load(id));

Hibernate has to load deleted objects anyways, because things like lifecycle, cascades, etc. have to be handled.

hypernate · **Posted:** Mon Mar 22, 2004 8:04 pm

michael wrote:

Hibernate has to load deleted objects anyways, because things like lifecycle, cascades, etc. have to be handled.

That seems to presume that the record to delete is not already in the Session?

If the persistent object is already in the Session, I see no reason why Hibernate should checkNullability(). The already-in-Session object can be used for Lifecycle callbacks, cascades, etc.

gavin · **Posted:** Mon Mar 22, 2004 10:17 pm

Sometimes it is necessary to UPDATE before DELETEing (eg. if there are circular foreign keys or something).

hypernate · **Posted:** Mon Mar 22, 2004 11:13 pm

I cannot think of a situation where the record to be deleted needs to be updated first, irrespective of its FKs. I can imagine that other, dependent records might need to have their FKs nullified in anticipation of the parent's deletion, but again that would not require the parent to be updated.

It sounds like this is something Hibernate is doing in properly maintain graphs of objects cached in the Session, which is in some cases overkill. Might be nice to make this tunable/configurable, or perhaps just "smarter".

gavin · **Posted:** Mon Mar 22, 2004 11:17 pm

Ummmm. I just told you the case. Circular foreign key references.

I will not be changing this functionality. Thanks for your suggestion.

hypernate · **Posted:** Mon Mar 22, 2004 11:41 pm

Brevity is the soul of wit, eh?

Perhaps you could provide a bit more detail or an example, because I don't "see it". I would appreciate understanding this.

gavin · **Posted:** Mon Mar 22, 2004 11:42 pm

Code:

class Bid {
    Item item;
}

class Item {
     Set bids;
     Bid successfulBid;
}

Code:

session.delete(item);

hypernate · **Posted:** Mon Mar 22, 2004 11:53 pm

I still fail to see why the ITEM record would be updated in the database. I can see why associated BID records might be updated or deleted. How the Hibernate Session manages the cached Java objects is an altogether different matter.

In any case, I appreciate the prompt replies. Let's not pursue this further as we may be arguing over semantics (exactly which record is updated, updated in the database or the Session, etc.) and I would prefer to save the Hibernate team's goodwill for a time when I am in dire need of assistance :)

So thanks!

ko5tik · **Posted:** Tue Mar 23, 2004 10:38 am

gavin wrote:

Code:

class Bid {
    Item item;
}

class Item {
     Set bids;
     Bid successfulBid;
}

Code:

session.delete(item);

HI Gavin, what cascade setting shall I use to avoid updating
dependent entities? "delete" "delete-orphan"?