Z tego, co wiem, strategia GeneratedValue jest zarezerwowana dla klucza podstawowego, co oznacza, że możesz jej użyć tylko raz na jednostkę.
W zależności od potrzeb masz jednak kilka opcji:
-
Zawsze możesz mieć prePersist wydarzenie cyklu życia , ustawiając dowolną wartość dla nazwy przed utrwaleniem jej po raz pierwszy.
-
Jeśli zależy Ci na tym, aby wygenerować z niego inny unikalny id, możesz zaimplementować zdarzenie postPersist, ustawić tam swoją nazwę i upewnić się, że opróżniłeś dwa razy (pierwszy raz, aby wygenerować klucz podstawowy, drugi raz, aby zapisać nazwę).
-
Jeśli nie masz nic przeciwko temu, że nazwa jest pusta w bazie danych przez jakiś czas, możesz zaimplementować zdarzenie postLoad, które wypełnia nazwę, jeśli jest pusta. W ten sposób Twoja aplikacja zawsze widzi nazwę (ponieważ jest ona ładowana z bazy danych lub wypełniana przez zdarzenie postLoad), a kiedy dodajesz lub edytujesz informacje po raz pierwszy po pierwszym zapisie, Twoja nazwa również zostanie zapisana
-
Może być w porządku, aby nie zapisać nazwy i wygenerować ją przez jakiś cronjob/deamon/queue, aby Twoja aplikacja nie musiała się tym zajmować. Jedyne, co musisz zrobić, to upewnić się, że brakujące imię niczego nie zepsuje.
-
Może byłoby w porządku wygenerowanie klucza, który nie zależy od klucza podstawowego, a zatem może zostać wygenerowany przez obsługa zdarzeń globalnych . Masz oczywiście tę wadę, że taki program obsługi zdarzeń, ponieważ jest globalny, jest wywoływany dla każdego utrwalonego obiektu, bez względu na to, czy jest to poprawna encja.
-
Wreszcie, ale nie mniej ważne, może być w porządku, aby wrócić do Stored Procedures/Triggers, aby pozwolić bazie danych obsłużyć to. W ten sposób nie będziesz musiał zadzierać z tym w swojej aplikacji. Ale uważaj, mogą pojawić się pułapki (np. programista zapominający o tym, ponieważ nie ma tego w kodzie, ale w bazie danych!).
Mogą być inne sposoby. To, co próbowałem powiedzieć, to:nie używaj wartości generowanej dla właściwości klucza innego niż podstawowy!
