Hello,

I love the all-delete-orphan semantics for collections. I am trying to duplicate this idea with a one-to-one or even a many-to-one relationship.

For instance, I would like to see the following happen:

foo = new Foo()
bar = new Bar()

foo.setBar(bar) <-- saves bar

bar2 = new Bar()

foo.setBar(bar2) <-- deletes bar, saves bar2

I keep contorting my API (by adding much business logic to move objects around and delete objects) to handle this type of situation. I'm almost at the point where I'll introduce AOP just to handle this situation. I obviously don't want my Foo object to have references to the DAO/Hibernate logic, or this would be very easy to solve.

Maybe a JavaBeans w/ PropertyChangeEvent solution would solve this?

I keep thinking that because Hibernate is wrapping all these objects in a proxy anyway, that it should have all the information required to do so. In fact, I seem to be able to do it all in an Interceptor, except Session access isn't allowed in an Interceptor.

Any ideas or past experiences with this?
Thanks very much!
Seth

If your "many-to-one" or "one-to-one" associated object B has to be deleted from the database if the reference from A is removed, you have simply an aggregation relationship. You map B as a value type of entity A, for example with a <component> or a <property> with a UserType or something.

There is no reason to make B a standalone entity if it is never referenced by another entity (say, there is no C that references B).

Thanks Christian,

That's a great point, and I forgot to ask specifically about that.

Specifically, we're talking about:

Person
Address

A single address will belong to one Person, but we'd like to have two tables. There are many other types of things that have Addresses.

It's my understanding that using <component> will map those Address columns into Person table. That is not quite ideal, and that will be a hard sell. A <component> does capture the semantics perfectly, though.

So a refinement on my question is: can I achieve <component> semantics but keep the two tables with a many-to-one or one-to-one? I know I can get a one-to-many w/ <component> and use two tables.

It's almost like I want to move the bag + <component> semantics over to a many-to-one. That is, delete what was there and replace it with this new thing. Sure, a bag isn't as effecient as a list eg, but still works fine.

Thanks!
Seth

A much stronger point is that two tables would be not normalized.

Sorry, can you please elaborate on your last point?

Uh, forget that, it is of coursed normalized.

Here's a flushed out example. Please let me know if the only way to do this is to use <component>. Ideally, I'd like to use many-to-one.

Person M:1 billingAddress
Person M:1 mailingAddress

Table Person:
billingAddressFK fk -> Address Table
mailingAddressFK fk -> Address Table

And then, of course:

person.setBillingAddress(addr1) <-- saves addr1
person.setBillingAddress(addr2) <-- deletes addr1, saves addr2

I know Hibernate can do this, even if it means it would always do this:

onSetOfPropertyWithSpecialOrphanDelete() {
if property existed before set:
delete it
save new property
}

Anyway, your tips are very much appreciated!
Thanks,
Seth

Can't map this with a component. You can open a JIRA issue and see what others think about a foreign key mapping for components. Certainly much better than any "orphan" pseudo-semantics for entities.

OK, thanks! Gavin shot down a previous proposal, but I like the idea of a FK component a lot better than what I was proposing. Thanks, wish me luck. :)

JIRA Improvement Request Filed:

http://opensource.atlassian.com/project ... se/HB-1010

Thanks for the suggestion, and put in a good word for me. :)

Oh gawd, I have already explained that this cannot be implemented. Please lets end this discussion here. Orphan delete for a many-to-one is anyway semantically incorrect! (A one-to-one might make sense.)

Actually, I suppose that orphan-delete for one-to-one could be implemented. (But not many-to-one.)


OTOH, creating a "foreign key component" is an incredibly bad idea.

OK, I'll let it drop. I was merely trying to think of another way to solve this problem.

Could you please explain why it would be an incredibly bad idea? Maybe with that extra information, I would see the real source of the problem. Obviously I don't understand why this is such a bad proposal.

Hello,

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

How did you eventually "solve" your requirement ?

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

Kind regards,
Edwin

I'm also struggeling on this one. Gavin says that "orphan delete for a many-to-one is anyway semantically incorrect!"

But the reason I'm using a many-to-one for my one-to-one relationship (spread over two tables, NO components here) is simply that Hibernate forces me to do so. From "Hibernate in Action", p. 221f

>>
Using a foreign key association

The easiest way to represent the association from User to its billingAddress is to use a <many-to-one> mapping with a unique constraint on the foreign key. This may surprise you, since many doesn’t seem to be a good description of either end of a one-to-one association! However, from Hibernate’s point of view, there isn’t much difference between the two kinds of foreign key associations. [...] Probably, cascade="all" makes sense for this association, since deletion of the User should result in deletion of the Address. (Remember that Address now has its own entity lifecycle.)
<<

I don't get the last sentence in the context of this forum thread: cascade deletion is excactly what does NOT WORK. Can somebody please shed some light on this?