JPA /休眠：ManyToMany删除联接表上的关系

Question

Disclaimer: This is my first Java project; learning as I go.

Background: I've inherited a legacy database on which to build a new RESTful API. We're using Elide with Spring Boot to provide a JSON API compliant service.

Reference: Example source code

Problem: We have entities with a many-to-many relationship to each other and themselves by way of a join table. Consider the followig schema:

CREATE TABLE ALPHA (
  ID VARCHAR(255),
  NAME VARCHAR(255),
  CONSTRAINT PK_ALPHA PRIMARY KEY (ID)
);

CREATE TABLE BRAVO (
  ID VARCHAR(255),
  NAME VARCHAR(255),
  CONSTRAINT PK_BRAVO PRIMARY KEY (ID)
);

CREATE TABLE RELATIONSHIP (
  ID INT AUTO_INCREMENT,
  FROM_ID VARCHAR(255),
  TO_ID VARCHAR(255)
);

Where the resource entities are modeled as follows:

public class Alpha implements Serializable {

    private String id;
    private String name;
    private Set<Alpha> alphas = new HashSet<>();
    private Set<Bravo> bravos = new HashSet<>();

    @Id
    @Column(name = "ID", unique = true, nullable = false)
    @GeneratedValue(generator = "uuid")
    @GenericGenerator(name = "uuid", strategy = "uuid")
    public String getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
    @JoinTable(
            name = "RELATIONSHIP",
            joinColumns = @JoinColumn(name = "FROM_ID"),
            inverseJoinColumns = @JoinColumn(name = "TO_ID")
    )
    public Set<Alpha> getAlphas() {
        return alphas;
    }

    @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
    @JoinTable(
            name = "RELATIONSHIP",
            joinColumns = @JoinColumn(name = "FROM_ID"),
            inverseJoinColumns = @JoinColumn(name = "TO_ID")
    )
    public Set<Bravo> getBravos() {
        return bravos;
    }

}

And the relationship table:

public class Relationship implements Serializable {

    private Integer id;
    private String fromId;
    private String toId;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    public Integer getId() {
        return id;
    }

    @Column(name = "FROM_ID")
    public String getFromId() {
        return fromId;
    }

    @Column(name = "TO_ID")
    public String getToId() {
        return toId;
    }

}

Now let's say we have an Alpha record A1 with relationships to A2 , A3 , B1 , and B2 . First we delete the relationship to A2 .

From our API this would be a DELETE request to http://localhost:9000/api/alphas/a1/relationships/alphas with BODY

{
  "data": [
    {
      "type": "alphas", 
      "id": "a2" 
    }
  ]
}

Behind the scenes Hibernates does what I'm expecting and generates the following SQL queries:

2018-07-13 09:48:23.687 DEBUG 7964 --- [nio-9000-exec-5] org.hibernate.SQL                        : 
Hibernate: 
    select
        alpha0_.id as id1_0_,
        alpha0_.name as name2_0_ 
    from
        alpha alpha0_ 
    where
        alpha0_.id in (
            ?
        )
2018-07-13 09:48:23.688 TRACE 7964 --- [nio-9000-exec-5] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [VARCHAR] - [a1]
2018-07-13 09:48:23.690 DEBUG 7964 --- [nio-9000-exec-5] org.hibernate.SQL                        : 
Hibernate: 
    select
        alphas0_.from_id as from_id2_2_0_,
        alphas0_.to_id as to_id3_2_0_,
        alpha1_.id as id1_0_1_,
        alpha1_.name as name2_0_1_ 
    from
        relationship alphas0_ 
    inner join
        alpha alpha1_ 
            on alphas0_.to_id=alpha1_.id 
    where
        alphas0_.from_id=?
2018-07-13 09:48:23.690 TRACE 7964 --- [nio-9000-exec-5] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [VARCHAR] - [a1]
2018-07-13 09:48:23.699 DEBUG 7964 --- [nio-9000-exec-5] org.hibernate.SQL                        : 
Hibernate: 
    select
        alpha0_.id as id1_0_,
        alpha0_.name as name2_0_ 
    from
        alpha alpha0_ 
    where
        alpha0_.id in (
            ?
        )
2018-07-13 09:48:23.699 TRACE 7964 --- [nio-9000-exec-5] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [VARCHAR] - [a2]
2018-07-13 09:48:23.721 DEBUG 7964 --- [nio-9000-exec-5] org.hibernate.SQL                        : 
Hibernate: 
    delete 
    from
        relationship 
    where
        from_id=? 
        and to_id=?
2018-07-13 09:48:23.722 TRACE 7964 --- [nio-9000-exec-5] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [VARCHAR] - [a1]
2018-07-13 09:48:23.724 TRACE 7964 --- [nio-9000-exec-5] o.h.type.descriptor.sql.BasicBinder      : binding parameter [2] as [VARCHAR] - [a2]

The key piece being delete from relationship where from_id=? and to_id=? delete from relationship where from_id=? and to_id=?

Now the problem arises when trying to delete the second Alpha relationship A3 , in which Hibernate does almost the exact same sequence, except for the DELETE query which omits the and to_id=? from the query, ie

Hibernate: 
    delete 
    from
        relationship 
    where
        from_id=?

Which has the unintended consequence of deleting all other A1 relationships in the table, ie B1 and B2 .

So that is the crux of my problem. It seems like Hibernate is only seeing one other related Alpha record and therefore deciding to simplify the query by omitting the and to_id statement.

I'm probably missing something terribly obvious!

I should also point out that I attempted to use a composite key on the relationship table but to no avail.

Answer 1

This is an unusual design, which I suspect is confusing Hibernate . Sharing a single join table between multiple Many-to-many relationships, isn't good database design, for one it can't have any foreign keys/referential integrity.

Secondly, Hibernate manages relationships, and therefore has control over the @JoinTable , I don't know how it would handle multiple entity relationships mapped with the same table. Evidently, not very well though!

The simplest solution (if you're able to), would be to have 2 mapping tables. One for the relationship between Alpha-Alpha and another between Alpha-Bravo .