ID do topico

Opa Lucas, tudo bem?

Então na verdade, na hora de salvar no banco, a sua aplicação envia o objeto pronto sem o id, o banco atribui o proximo id que é gerenciado por ele e salva o objeto com todos os parametros definidos, na hora que você recupera o objeto esse id que foi gerado pelo banco pode ser facilmente recuperado junto com os outros dados.

Aqui tem um post de curiosidade que ensina os diferentes tipos de geração de ids do banco de dados: https://www.alura.com.br/artigos/entendendo-a-geracao-de-chaves-com-jpa

Caso tenha ficado alguma duvida, pode perguntar!

Então, mas no exemplo da aula, em que momento está sendo buscado esse novo topico (depois de salvo)?

    @PostMapping
    public ResponseEntity<TopicoDto> cadastrar(@RequestBody TopicoForm form, UriComponentsBuilder uriBuilder) {
        Topico topico = form.converter(cursoRepository);
        topicoRepository.save(topico);

        URI uri = uriBuilder.path("/topicos/{id}").buildAndExpand(topico.getId()).toUri();
        return ResponseEntity.created(uri).body(new TopicoDto(topico));
    }

esse é o código, o save recebe o topico, sem id, e dps ele faz o build da url do topico com o id, sendo que o topico é o mesmo desde o início do processo

Me desculpa não tinha visto. Então como o hibernate controla o ciclo de vida desse cara, a partir do momento em que você chama o save, seu objeto está em um estado managed e aí o hibernate consegue “settar” esse id.

certo! Obrigado.

Ainda estou com dpuvida sobre isso. É correto afirmar que o hibernate cuida do ciclo de vida da transação nesse contexto? Em nenhum momento é aberta uma transação explixitamente, imagino que o spring esteja cuidando disso e não o hibernate.