Referential integrity with One to One using hibernate

Question

I'm having two tables -

Foo { foo_id, name }
Foo_properties { fp_id, foo_id, phoneNumber}

Now I want to map this in my object model using hibernate.. I need a foo_id in Foo_properties because i want to maintain referential integrity and want to add ON DELETE CASCADE constraint.
so I mapped the relation in the following way -

@Entity
public class Foo{
    @Id
    private long foo_id;

    private String name;

    @OneToOne(mappedBy = "foo")
    private FooProperties fooProperties;
}

@Entity
public class FooProperties{

    @Id
    private long fp_id;

    private String phoneNumber;

    @OneToOne
    @JoinColumn(name = "foo_id",  nullable = false)
    private Foo foo;
}

Now since the owning side is FooProperties class, I'm facing following issues -

If I set the new instance of FooProperties to Foo the existing FooProperties still remains in DB and hibernate doesn't delete that instance, e.g.

Foo foo = entityManager.find(Foo.class, fooId);
foo.setFooProperties(new FooProperties("xxx-xxx-xxx"));
entityManager.merge(foo);

This results into the new row in FooProperties table along with the existing one. Now I don't understand how I can change my mapping to so I can have above code (or variant of it) working for all scenarios, that means I need Foo as a owning side and foo_id in FooProperties. Is there any way to define the mapping like this?

NOTE: I already asked question based on this but I think I wasn't clear in previous question so asked this another one.

in Foo? if so then doesn't work.. since owner side is different and also it is deprecated — Premraj, Mar 22 '11 at 10:36

score 4 · Accepted Answer · answered Mar 22 '11 at 11:17

You were already told to use orphanRemoval = true or CascadeType.DELETE_ORPHAN. However, due to casuistics in interpretation of JPA Specification it wouldn't work as expected for one-to-one relationships (HHH-5559).

You can achieve a proper behaviour of orphanRemoval with the following trick:

@Entity
public class Foo{
    @OneToMany(mappedBy = "foo", orphanRemoval = true)
    private List<FooProperties> fooProperties;

    public FooProperties getFooProperties() {
        if (fooProperties == null || fooProperties.isEmpty()) return null;
        else return fooProperties.get(0);
    }

    public void setFooProperties(FooProperties newFooProperties) {
        if (fooProperties == null) fooProperties = new ArrayList<FooProperties>();
        else fooProperties.clear();
        if (newFooProperties != null)
            fooProperties.add(newFooProperties);            
    }
    ...
}

@Entity
public class FooProperties{
    @ManyToOne
    @JoinColumn(name = "foo_id",  nullable = false)
    private Foo foo;
    ...
}

Or even this, if you don't need FooPropeties.foo:

@Entity
public class Foo{
    @OneToMany(orphanRemoval = true)
    @JoinColumn(name = "foo_id",  nullable = false)        
    private List<FooProperties> fooProperties;

    // getter/setter as above
    ...
}

Thomas · Answer 2 · 2011-03-18T18:44:53.900

0

Bar is the owner of the association (as indicated by the mappedBy on the inverse side) and thus the cascade has to be set there.

Edit:

To invert that, this might help.

edited Mar 18 '11 at 18:44

answered Mar 18 '11 at 18:38

Thomas

87,414
12
119
157

@Thomas - yes.. agree. but I guess problem won't be solved, right? – Premraj Mar 18 '11 at 18:43
Depends on what the problem is. Your two points should be solved with that, but for meeting your requirements as well please see my edit. Maybe this helps. – Thomas Mar 18 '11 at 18:46
@Thomas - Doing so will not resolve the problem. It only implies that delete the related foo record when bar is deleted where as the requirement is different – Satadru Biswas Mar 18 '11 at 18:50
@Thomas - yes.. Doing some POCs based on that.. Thanks for sharing.. Will update you on this :) – Premraj Mar 20 '11 at 13:15
@Thomas - Seriously thinking about simulating a OneToOne using a OneToMany JoinTable.. but wondering whether this is good practice or not :) – Premraj Mar 21 '11 at 10:31
I don't think you have to use a Join Table. Did you try the suggestions about the target foreign key? – Thomas Mar 21 '11 at 10:38

score 0 · Answer 3 · answered Mar 18 '11 at 18:49

0

There are 2 options for you to choose from, since you don't want to change your mapping :

Do it via your service layer logic. I think you have a similar question already.
Use the Hibernate annotation @Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN) on the Foo side of the relationship. However this is explicitly Hibenate and JPA 2 doesn't include support for the same.

answered Mar 18 '11 at 18:49

Satadru Biswas

1,555
2
13
23

yes.. I would like to skip the service layer approach, I'll try the @Cascade annotation of hibernate and will update you on this. – Premraj Mar 18 '11 at 19:08
@Premraj M - If you use the annotation, you will still have to set a null reference to Bar.foo, i.e. bar.setFoo(null), as then only will the bar instance be an orphan. Just doing a foo.setBar(toSomeOtherBar) will not do the trick. I believe this might even throw an exception as the relationship is one-to-one. – Satadru Biswas Mar 18 '11 at 19:29

score 0 · Answer 4 · answered Mar 22 '11 at 10:22

0

I think instead of calling merge on the entity, if you directly call update on session object then hibernate will first delete the existing row and then it will add the new one. I implemented the same, but, in my case I used xml for mapping the entity. I hope this will help you.

answered Mar 22 '11 at 10:22

Naved

4,020
4
31
45

1

Why should Hibernate delete the exisiting row? It doesn't do so. – axtavt Mar 22 '11 at 10:24
I am talking about FooProperties (inner table) and not about Foo. The log of hibernate shows that it first deletes inner table data and then adds the new one. – Naved Mar 22 '11 at 10:30

Referential integrity with One to One using hibernate

4 Answers4

Linked