OneToMany Spring Data JDBC

@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<>(); }

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.

Recommended topics

Hot tags