the problem here is I defined the hbm mapping file by myself:
I first generated a hbm file using middlegen,then I manually
deleted the association definitions as below,for the BO here
need not to be aware of the loading of these sets,I delete
these definitions for the sake of simpleness of this BO.

<set
name="clips"
lazy="true"
inverse="true"
cascade="all"
>
<key>
<column name="article_id" />
</key>
<one-to-many
class="com.libInformation.bo.Clip"
/>
</set>
....
here comes the question,the set definitions are gone,there's
nowhere to define the cascade property;then when deleting this
BO it turns out that "a foreign key constraint fails"

how to handle this situation?can I keep my hbm-file unchanged
and simultaneously handle the deleting problem?

hibernate3 has adapted the EJB3 spec following delete criteria. Unless you're in the same session as an object was loaded (or that you've persisted with that session), it will not cascade the deletes automatically. This is to improve performance becuase H used to load everything into memory then delete everything... which is alot of extra work.

I recommend writing custom delete sql/hql statements which have much better performance...

another less performant way is to just call delete on every object in a set, then null out the set, then delete the parent

thank you for replay:)

what's EJB3's delete criteria?



in this way need I change the database DDL to change the reference to
be "ON DELETE CASCADE"?or I don't know how to write a single hql to
do the job..

I think kochcp may be confusing the HQL DELETE statement. It sounds like you are just trying to do : session.delete( someEntity ), right?

Hibernate can only cascade operations to stuff it knows about, and it only knows about stuff you have told it about in the metadata. Since you have removed that association from the metadata (the mapping file) Hibernate has no way to know that it should be doing a cascade to those rows.

So your two options are (1) anually delete all related Clip rows; (2) use of DB-level cascading constraints.

Not that #2 causes problems here also since there is a potential for rows to be get deleted where Hibernate knows nothing about those deletes.