Ссылка на другой объект при чтении, но сохранение только с идентификатором - PullRequest
Новая
       7

Ссылка на другой объект при чтении, но сохранение только с идентификатором

0 голосов
/ 25 марта 2020

У меня есть отношение «один ко многим», как описано ниже: 

@Entity
@Table(name = "some")
data class SomeEntity(
    val otherId: UUID,

    @Column(nullable = false)
    val number: String = "12345",
) {
    @Id
    @Column(updatable = false, nullable = false, unique = true)
    val id: UUID = UUID.randomUUID()
}

@Entity
@Table(name = "other")
data class OtherEntity(
    @Id
    @Column(updatable = false, nullable = false)
    val id: UUID = UUID.randomUUID(),
)

Мне не нужно указывать, что это аннотация @OneToMany или @JoinColumn.

С помощью этой структуры я могу сохранить новый OtherEntity, и после этого я могу сохранить новый SomeEntity, передав ранее возвращенный идентификатор 

val ent1 = OtherEntity()
val savedEnt1 = otherRepository.save(ent1)

val ent2 = SomeEntity(savedEnt1.id, "123")
val savedEnt2 = someRepository.save(ent2)

То, чего я пытаюсь добиться, - это возможность получить OtherEntity. объект из объекта SomeEntity. 

val other: OtherEntity = ent2.other

Если я просто добавлю всю сущность в конструктор, я должен передать всю OtherEntity каждый раз, когда я хочу сохранить новую SomeEntity

Как мне просто создать ссылку на OtherEntity, не имея ее в конструкторе?

1 Ответ

1 голос
/ 25 марта 2020

То, что вы пытаетесь достичь, это вопреки идее JPA. То есть инкапсулировать слой постоянного хранилища базы данных и скрыть его, чтобы вы могли работать с объектами JVM без необходимости отражать, как их данные должны быть организованы, чтобы это имело смысл в базе данных отношений.

Как вы, наверное, знаете, @Entity является одной из базовых c концепций JPA. Реализуя и аннотируя ссылку одного @Entity на другой, вы позволяете JPA понять, какие операторы SQL он должен подготовить заранее, чтобы использовать их для запросов к базе данных, а также какие ограничения он должен применять к таблицам и столбцам. Это не может быть вычислено на основе ошибочного и упрощенного c предположения о том, что поле xyzId, очевидно, должно быть ссылкой на первичный ключ Xyz сущности.

Более того, тот самый код, который вы хотели бы использовать добивайтесь прямых результатов, если хотите, чтобы у вашего класса SomeEntity было поле other: OtherEntity, а не otherId: UUID. Но поскольку одна сущность должна храниться в другой таблице, а не в другой, в соответствии с принципами RDMS, именно поэтому JPA используется в первую очередь - для тяжелой работы, связанной с полем, хранящим внешний ключ для другой таблицы, хранящейся в одна модель, так что указанный ключ может быть использован для ручного извлечения данных из другой таблицы.

Сделайте шаг назад и пересмотрите свои предположения. Помните, что наличие отношений, определенных между вашими @Entity классами, не обязательно подразумевает постоянную перегрузку данных - так как эти связанные объекты могут быть загружены ленивым по требованию, если это необходимо.

...