OneToMany Spring Data JDBC

Question

I want to model a OneToMany Relation with Spring Data JDBC. I´ve read on this very useful blog https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates that you should use references when you want to model ToMany Reference:

Therefore any Many-to-One and Many-to-Many relationship must be modeled by just referencing the id.

So I have this scenario:
One Student can have multiple Registration. And one Registration can have exactly one Student. If you delete Registration the assigned Student should not get deleted cascading.
I ended up with this modelling:

@Data
@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))
public class Registration {

    private final @Id
    @Wither
    long registrationId;

    @NotNull
    private String electiveType;

    @NotNull
    private LocalDateTime created = LocalDateTime.now();

    @NotNull
    private StudentRegistrationReference studentRegistrationReference;

}

@Data
@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))
public class StudentRegistrationReference {
    private long student;
    private long registration;
}

@Data
@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))
public class Student {

    private final @Id
    @Wither
    long studentId;

    @NotNull
    @Size(min = 4, max = 20)
    private String userId;

    @NotNull
    @Min(0)
    private int matriculationNumber;

    @NotNull
    @Email
    private String eMail;

    private Set<StudentRegistrationReference> studentRegistrationReferences = new HashSet<>();

}

My question is whether my modeling is correctly implemented?

Jens Schauder · Accepted Answer · 2018-11-20T06:13:39.743

You are quoting the article talking about "Many-To-X" but you talk yourself about "X-To-Many". You can model a One-To-One or a One-To-Many relationship with a direct reference, or a List/Set/Map of entities.

What you should avoid are bidirectional relationships. While you probably can make them work with the approach you are using, you really shouldn't.

Which brings us to the question: How should this model look like?

The central decision to make is how many aggregates are involved?

A Student certainly is an aggregate and the Student class is its aggregate root. It can exist on its own.

But what about Registration? I'd argue, it is probably part of the same aggregate. The delete test is a good one. If you delete a Student from the system, do the registrations of that Student still have value? Or should the disappear together with the Student?

As an exercise let's do both variants. I start with: Just one aggregate:

class Registration {

    @Id private long Id;

    String electiveType;
    LocalDateTime created = LocalDateTime.now();
}

class Student {

    @Id private long Id;

    String userId;
    int matriculationNumber;
    String eMail;
    Set<Registration> registrations = new HashSet<>();
}

With this, you would have a single repository:

interface StudentRepository extends CrudRepository<Student, Long>{}

I removed all the Lombok annotations since they aren't really relevant to the problem. Spring Data JDBC can operate on simple attributes.

If Registration and Student both are aggregates it gets a little more involved: You need to decide which side owns the reference.

First case: The Registration owns the reference.

class Registration {

    @Id private long Id;

    String electiveType;
    LocalDateTime created = LocalDateTime.now();

    Long studentId;
}

public class Student {

    @Id private long Id;

    String userId;
    int matriculationNumber;
    String eMail;
}

Second case: The Student owns the reference

class Registration {

    @Id private long Id;

    String electiveType;
    LocalDateTime created = LocalDateTime.now();
}

class Student {

    @Id private long Id;

    String userId;
    int matriculationNumber;
    String eMail;

    Set<RegistrationRef> registrations = new HashSet<>();
}

class RegistrationRef {

    Long registrationId;
}

Note that the RegistrationRef doesn't have a studentId or similar. The table assumed for the registrations property will have a student_id column.

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the `Student` by the `IStudentRepostory` will the `Set` being fetched with the `Registration` Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC? — Thomas Lang, Nov 20 '18 at 06:10
"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet). — Jens Schauder, Nov 20 '18 at 06:14
This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help! — Thomas Lang, Nov 20 '18 at 06:21
I need a complete picture, a quick look at https://stackoverflow.com/questions/53638091/spring-data-jdbc-one-to-many-kotlin is much appreciated. — ielkhalloufi, Dec 05 '18 at 23:23
G.Mast: The above properties are just an excerpt from a real world application i am currently working on. So the final scripts are currently in progress. If this is done i can share a github repository here. Would this be cool for your in the meantime? — Thomas Lang, Dec 20 '18 at 07:20

OneToMany Spring Data JDBC

1 Answers1