Zabezpieczenie przed wrzuceniem duplikatu do bazy

0

Cześć, tak jak w temacie chciałbym dodać w aplikacji zabezpieczenie przed wrzuceniem zduplikowanego rekordu do bazy danych. Moja encja prezentuje się następująco:

@Entity
public class Book {
    @Id 
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String bookId;
    private String authorId;
    @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name = "book_info_id")
    private List<BookDetails> bookDetails;
}

Chciałbym, żeby nie dało się dodać książki jeśli takie same pola bookId i authorId znajdują się w już istniejącym rekordzie w bazie. Próbowałem zdefiniować uniqueConstraints:

@Table(uniqueConstraints = { @UniqueConstraint(columnNames = { "bookId", "authorId" }) })

i to rozwiązanie jak najbardziej działa, tylko ten constraint zakładany jest jedynie przy tworzeniu tabeli w bazie a ja chciałbym dodać to zabezpieczenie do istniejącej już tabeli. Próbowałem coś kombinować z composite key, ale nie wiem jak mogę poradzić sobie z polem id, gdyż chciałbym, żeby zostało i wartość dalej była generowana wg, aktualnej strategii. Może moglibyście mi doradzić co mogę zrobić, żeby uzyskać zamierzony efekt?

3

i to rozwiązanie jak najbardziej działa, tylko ten constraint zakładany jest jedynie przy tworzeniu tabeli w bazie a ja chciałbym dodać to zabezpieczenie do istniejącej już tabeli

Może jestem trochę zbiasowany bo nie lubię Hibernate ale proponowałbym oddzielenie struktury bazy od frameworka używanego do dostępu do danych. Używanie ORM do generacji i zarządzania DDL wydaje mi się złym pomysłem. Zamiast tego Flyway + DDL napisany ładnie w SQLu - wtedy dodanie constrainta to kwestia dodania małego kawałka SQL zamiast bawienie się w anotacjozę.

1

A co, jeśli w tabeli już są duplikaty?

0

Na razie w bazie nie ma duplikatów bo i danych nie ma za wiele, ale to fakt, że nie pomyślałem o sytuacji gdy w bazie są już zduplikowane rekordy.
Dobrze, że zadałem pytanie tutaj bo przyblokowałem się na tym a Damian szybko podsunął mi najlepsze rozwiązanie

0

JPA ma liczne problemy, ale używając zgodnie z duchem coś w zamian za to daje.
Tu mam na myśli m.in. referencje na (jakby) klucze obce. Pisze się to w kodzie Javowskim obiektowo, a w bazie generowany jest prymityw z kluczem.

Używając "ręczne" klucze obce nadal masz wszystkie uciążliwości, a nie masz zalet.
Lepiej by było dowolnym prostym maperem

Źle się czyta ta klasa ... czytam i widzę, że jest to klasa Book, i ma klucz własny id.
Ale co czytam dalej ... jest jakiś klucz o nazwie bookId, czyli pewnie na jakiś Book
Jeśli to nie jest to, co myślę, to nazwij tak, jak naprawdę się nazywa

1 użytkowników online, w tym zalogowanych: 0, gości: 1