Fala aí Alexandre, tudo bem?

Então o @JoinColumn é somente para você definir qual o nome da coluna deve ser usada para FKs. Caso você não especifique ele utiliza o padrão que seu eu não me engano é o nomeclasse_id.

[]s

@Fernando Furtado, mais qual seria a solução para continuar usando os dados do banco sem dar o drop na base e adicionar o controle com o Join para não ter duplicidade?

Exemplo de entidade Cliente que tem uma Conta.

+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| endereco  | varchar(255) | YES  |     | NULL    |                |
| nome      | varchar(255) | YES  |     | NULL    |                |
| profissao | varchar(255) | YES  |     | NULL    |                |
| conta_id  | int(11)      | YES  | UNI | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+

No caso eu teria que acessar a base e criar manualmente esta coluna "conta_id" e depois adicionar o JoinColumn ?

Então acho que não entendi direito,

Na sua entidade tem a anotação @OneToOne que gera a coluna conta_id. E você quer substituir conta_id por alguma outra coisa que você quer informa no @JoinColumn seria isso?

O ideal é não permitir que o hibernate altere a estrutura do seu banco em produção. Já que vc não tem garantias do que ele fará como nesse caso. O mais correto é usar alguma ferramenta de migração como o Flyway por exemplo, onde vc cria scripts que farão as devidas atualizações e tratamentos. Até achei estranho o instrutor não indicar isso na aula :/

@Fernando Furtado sim tenho o @OnetoOne e uso o @JoinColumn(unique=true) para garantir que não terei risco de inserir novamente o mesmo ID em minha entidade Cliente.

Porém no curso do João, ele informa que é necessário dar um drop na base caso não tenha adicionado o @JoinColumn(unique=true) antes de criar a base. ou seja, vim ao forum porque achei isto muito estranho, como vou dar um drop em uma base de produção que atualmente ja esta funcionando e cheio de dados... por isso criei este novo tópico.

Mas creio que a solução do @Fausto Bertin deve funcionar, agora na pratica eu não sei pra onde vai. ou como resolve este problema sem dar um drop no banco.

@Fausto Bertin poderia postar um tutorial ? ou algum link que de a solução usando as informações que você respondeu.

Abs. Obrigado.

Boa noite @Slinkey99.

De forma resumida, ferramentas de migração possuem um funcionamento bastante simples. Você criará scripts sqls e os nomeará com uma estrutura padrão algo como:

V1_1__cria_tabela_teste.sql
V1_2__altera_tabela_e_ajusta_indice.sql

Com base nisso a biblioteca irá se encarregar de verificar quais scripts já foram executados, quais não, a ordem de execução e afins. Depois ele registra em uma tabela os scripts que foram rodados a data e demais informações.

O qual eu uso é o Flyway, porque além de ser super simples, sempre atendeu minhas necessidades, mas existem outras opções também.

Na página: https://flywaydb.org/getstarted/ (clique na aba Java lá embaixo) É possível usá-lo através de código java msm, ou ainda linha de comando, maven e afins.

E basicamente é isso, os tutoriais que achei aqui são em inglês, não sei se te ajuda :/ Faça uma backup do seu banco e tente usá-lo, qualquer dúvida avise ai que tento te ajudar melhor.

Valeu, até.

@Fausto Bertin bom dia!

Obrigado pelas dicas, ainda não consegui efetuar o procedimento. mas considerei como resolvido sua solução.

Na verdade eu estou estudando, não tenho nada em produção, mas creio que mais na frente um dia irei me deparar com isso, por isso fiz a pergunta e como o professor não deixou bem claro, veio aquela dúvida que certamente um dia irá acontecer.

Ainda não tive a oportunidade trabalhar na área de desenvolvimento, mas em breve estarei trabalhando se deus quiser, quero estar bem preparado pra não passar vergonha rsrsrs.

Abs tudo de bom.