Pelo que sei, a estratégia GeneratedValue é reservada para a chave primária, o que significa que você só pode usá-la uma vez por Entidade.
Dependendo de suas necessidades, você tem algumas opções:
-
Você sempre pode ter um evento de ciclo de vida prePersist , definindo qualquer valor que desejar para o nome antes de persisti-lo pela primeira vez.
-
Se você depender do id para gerar outro id exclusivo a partir dele, poderá implementar um evento postPersist, definir seu nome lá e certificar-se de liberar duas vezes (a primeira vez para gerar a chave primária, a segunda vez para salvar o nome).
-
Se estiver tudo bem para você que o nome esteja vazio no banco de dados por algum tempo, pode ser bom implementar um evento postLoad, que preenche o nome se estiver vazio. Dessa forma, seu aplicativo sempre vê o nome (porque é carregado do banco de dados ou preenchido pelo evento postLoad) e quando você adiciona ou edita informações pela primeira vez após o salvamento inicial, seu nome também será salvo
-
Pode ser bom não salvar o nome e tê-lo gerado por algum cronjob/deamon/queue para que seu aplicativo não precise lidar com isso. A única coisa que você precisa fazer é garantir que um nome ausente não estrague alguma coisa.
-
Talvez não haja problema em gerar uma chave que não dependa da chave primária e, portanto, possa ser gerada por um manipulador de eventos global . É claro que você tem a desvantagem de que esse manipulador de eventos, por ser global, é chamado para cada objeto que você persiste, não importa se é a entidade correta.
-
Por último, mas não menos importante, pode ser bom fazer fallback para Stored Procedures/Triggers para deixar o banco de dados lidar com isso. Dessa forma, você não precisa mexer com isso dentro do seu aplicativo. Mas cuidado, pode haver armadilhas no caminho (como um desenvolvedor se esquecendo disso porque não está no código, mas no banco de dados!).
Pode haver outras maneiras. O que eu estava tentando dizer é:Não use generateValue para propriedades de chave não primária!
