Hello,

I'm using Hibernate 2.1.2. Is it possible to emulate the actions of all-delete-orphan with a many-to-one relationship? Specifically, given the following ordered actions (cascade="all" is enabled for the relationship):

foo.setBar(b1);
session.save(foo);

... later on ...

foo.setBar(b2);
session.update(foo);

I'd like Hibernate to then Delete b1, because it's no longer being referenced by anything.

My Bar objects can't be elements, they must be in their own table and not mapped columns of the parent table.

The semantics of a composite-element Bag would be perfect here, since that just does a DELETE on the bag, then an INSERT (dumb, but effective :)

I'm looking for the same type of action with a many-to-one. Any ideas, tips, or tricks?

Thanks very much!
Seth

ps Mapping files follow, though they just provide a snapshot into my intentions.

<hibernate-mapping>
<class
name="test.Bar"
table="BAR"
dynamic-update="false"
dynamic-insert="false">

<id name="id"
column="id"
type="java.lang.String">
<generator class="uuid.hex">
</generator>
</id>
</class>
</hibernate-mapping>

<hibernate-mapping>
<class
name="test.Foo"
table="FOO"
dynamic-update="false"
dynamic-insert="false">

<id name="id"
column="id"
type="java.lang.String">
<generator class="uuid.hex">
</generator>
</id>

<many-to-one name="bar1" class="test.Bar" column="bar1_id" unique="true" cascade="all"/>
<many-to-one name="bar2" class="test.Bar" column="bar2_id" unique="true" cascade="all"/>
</class>
</hibernate-mapping>

Wonder if I can get this functionality with an Interceptor?

You can emulate all-delete-orphan functionality for many-to-one relationship using component mapping for your Bar class in Foo mapping, but you had to put all BAR table columns into FOO table, maybe it is not too suitable for your task.
http://www.hibernate.org/hib_docs/reference/en/html/components.html

Leonid

After reviewing the Interceptor API, it looks like I could be able to detect when I have replaced an object reference (and thus delete the old referenced object). The problem is that we're not supposed to access the Session from the Interceptor's callback methods.

Some complicated event firing might do the trick, but that's not pretty.

Back to the drawing board.

Some background: Of course I could just have the client code session.delete(oldReferencedObject), but then the client code pops out of Java world and into Hibernate world. The client already is doing session.save(), session.delete(), but those seem more natural. I wish there was a way to tell hibernate "treat this object relationship like a persistence by reachability" (that is, if the parent object just let go, then delete the orphan).

In other words, emulate the nice all-delete-orphans, but for a single object (not a collection).

Thanks,
Seth

Yeah, I'm aware that I can make it a component and places all columns into one table. That's not really ideal, also because I might have 3 Bars to one Foo. The table structure for that would be pretty ugly.

I might look into Spring's AOP support, though if I do that, I think I'm just better off forcing my client code to call the delete(). More dangerous (what if client forgets?) but less complicated.

I know Hibernate knows when I dereference an object. I'm surprised I can't add some semantics to that relationship to help with deleting when dereferenced.

Hello,

Can you let me know what the final outcome is of this thread ?

How did you eventually "solve" your requirement ?

Should a client keep track of the deleted objects and then issue actual deletes for each of them, or did you use the interceptor approach or did you perhaps implement-the-Hibernate-LifeCycle-interface approach ?

The reason for asking is that I have the same requirement and I'm still doubting how to actually solve it.

Kind regards,
Edwin

Hi,

I finally got over wanting this feature.

I solved my problem by adding a copyFrom(Object o) method to most of my classes. That method copies everything except the ID. That way, if I have a new object that I want to use to replace the old object, I use that method. I avoid the need to delete anything, because the old object remains, it just has all new property values.

Essentially, I stopped trying to call setObject() all the time and hoping it would magically delete the old object and save the new object. Now I use getObject().copyFrom(newObject)

HTH,
Seth