Så vidt jeg ved, er GeneratedValue-strategien reserveret til den primære nøgle, hvilket betyder, at du kun kan bruge den én gang pr. enhed.
Afhængigt af dine behov har du dog et par muligheder:
-
Du kan altid have en prePersist livscyklushændelse , indstil enhver værdi, du kan lide for navnet, før du fortsætter med det første gang.
-
Hvis du er afhængig af id'et for at generere et andet unikt id fra det, kan du implementere en postPersist-begivenhed, sætte dit navn der og sørge for at tømme to gange (første gang for at generere primærnøglen, anden gang for at gemme navnet).
-
Hvis det er ok for dig, at navnet er tomt i databasen i nogen tid, kan det være ok at implementere en postLoad hændelse, som udfylder navnet, hvis den er tom. På denne måde ser din applikation altid navnet (fordi det enten er indlæst fra databasen eller udfyldt af postLoad-hændelsen), og når du tilføjer eller redigerer information første gang efter den første lagring, vil dit navn også blive gemt
-
Det kunne være ok ikke at gemme navnet og få det genereret af en eller anden cronjob/deamon/kø, så din ansøgning ikke skal håndtere det. Det eneste, du skal gøre, er at sørge for, at et manglende navn ikke ødelægger noget.
-
Måske kan det være ok at generere en nøgle, som ikke afhænger af den primære nøgle og dermed kan genereres af en global hændelseshandler . Du har selvfølgelig den ulempe, at en sådan hændelsesbehandler, fordi han er global, bliver kaldt for hvert objekt, du fortsætter, uanset om det er den korrekte enhed.
-
Sidst, men ikke mindst, kan det være ok at falde tilbage til Stored Procedures/Triggers for at lade databasen håndtere dette. På denne måde behøver du ikke rode med dette inde i din ansøgning. Men pas på, der kan være faldgruber på vej (som en udvikler, der glemmer dette, fordi det ikke er i koden, men i databasen!).
Der kan være andre måder. Det, jeg prøvede at sige, er:Brug ikke generedValue til ikke-primære nøgleegenskaber!