Salve, beleza? Continuamos essa saga aqui no Domain Dream Design. Então agora nós vamos nos concentrar em criar o mapeamento em entidade relacional. Pegando o caso do microRM, nós podemos fazer esse mapeamento diretamente ali dentro da entidade, utilizando decorators. Funciona dessa forma aí com Hibernate, com Doctate, com doctrine, normalmente com esses data mappers a gente vai colocando dessa forma, mas a gente não quer isso porque tem a influência da tecnologia ali poluindo o nosso domínio. Basicamente, usando o test form aqui, usando decorators, mas só usando uma outra... Não é metodologia, mas uma outra maneira para a gente poder lidar com os decorators. E é o que a gente vai fazer aqui, que é lidando com um cara separado para poder fazer esse mapeamento. Então, eu posso criar esse entity schema, colocar todos os campos, colocando ali, esse campo aqui vai ser string do tipo varchar e etc. Tem várias formas de a gente fazer esse mapeamento. Eu posso lidar até com a interface, ele gera para mim uma instância já dele, dessa entidade, ou eu posso passar a classe que se refere à entidade que eu estou mapeando. Então, eu já tenho aqui um exemplo para a gente poder começar com o nosso partner. Então, eu vou chamar aqui um partner esquema, que vai ser uma instância desse entity esquema dele, importando aqui do micro-rm-core. Aí aqui é um generic que ele precisa, vou importar o partner lá do nosso domínio, e aqui eu me refiro a ele. Olha onde que ele está. Primeira vez que a gente está trabalhando com a pasta infra. Então, aqui dentro da pasta db, eu tenho os meus schemas. Vou colocando os outros esquemas, tudo num arquivo só. Não vejo por que separar em vários. Então, está aqui a minha classe alva, minha classe limpinha. E o que eu tenho em Partner? Apenas dois campos. É muito interessante para a gente poder, na verdade, não só... Eu coloquei description. Ah, description é para o evento. Estou olhando isso aqui, estou achando que tem description em parte. Estava estranho. Só tem dois campos mesmo. O próprio name vai ser um varchar. Isso aqui ele vai transformar lá no varchar do MySQL. Com 255. Mas e o id? O id é uma primary key. Poderia colocar aqui um type uuid. Eu acho que nesse caso aqui ele acaba criando um char, um varchar lá do tamanho 36. Mas eu poderia trabalhar com um tamanho binário. E aqui ele está gerando esse uuid antes de salvar. Eu não quero que ele faça essa geração. Então, vamos trabalhar aqui dessa forma. Salvando aqui. Agora, num teste, a gente pode brincar aqui com um novo arquivinho. Vamos colocar assim, esquimas.spec.tf. esquimas.spec.tf Vamos criar aqui um teste deve criar um partner. Agora eu quero pegar um código do microRM, eu não quero perder tempo com essas devidas configurações. Eu já tenho aqui um código do microRM, eu não quero perder tempo com essas devidas configurações, eu já tenho aqui um código da devida documentação, a gente vai iniciar uma instância do microRM, então aqui eu tenho que importar esse cara do MySQL, o driver na verdade aqui é MySQL driver, nós estamos utilizando, O banco de dados vai chamar events, segundo o que está lá no Docker Compose, e o type aqui vai ser o MySQL mesmo. E aqui eu passo onde estão as minhas entidades. Eu posso tanto passar a entidade lá que está misturada junto com o mapeamento, ou justamente a instância do meu esquema. Então, aqui eu vou passar aquele partner esquema. Maravilha. Aqui precisa ser async, porque isso aqui devolve uma promessa. Vamos ver se a gente tem aqui um ORM, entity manager, que é o camarada que vai permitir que a gente faça as coisas. Então, vamos ver aqui. Está ali, a princípio deu tudo certo, mas a gente precisa passar mais coisas aqui. O user, que é root, e o password, que é root e o password que é root. Tá, foi de bola. Aqui no final das contas, é até bom que a gente faça um ORM close para poder fechar a conexão e o nosso teste fechá-la. Isso aqui também devidamente uma promessa, tem que colocar await. Bom, então vamos tentar aqui criar um partner. Eu poderia pedir para ele criar para mim a partir dessa inclusive o Copilot está dando a sugestão, mas o que a gente quer testar? Eu quero pegar um partner, fazendo um partner.create, passando o name. E aí, com esse EntityManager, que é o gerenciador das entidades, a gente chama ele de EM, eu vou pegar esse camaradinho aqui e faço um Persist. Volto para cá. E a gente precisa entender como que funciona esses Data Mappers. O Persist não faz nada no banco de dados. Ele apenas vai gerenciar essa entidade e depois a gente vai falar sobre o padrão do unit of work. Aí agora, a gente vai para poder fazer o disparo lá no banco de dados, nós vamos fazer o flush. Pode ficar tranquilo que a gente vai ver isso depois. Vamos executar isso aqui e ver o erro que ele vai mostrar aqui para a gente. Ele está falando que eu estou utilizando um Entity Manager global, então vamos fazer o seguinte aqui, vamos criar um fork que ele não quer que eu gere um Entity Manager global, então a gente gera um local. Eu acho que ele está com alguma questão aqui para poder conectar o host. Vou colocar aqui localhost e a porta 3306. Esse teste aqui, eu vou parar porque ele está tentando conectar ali, esperando algum resultado. E a operação foi abortada. E faz sentido, porque o flush aqui é uma promessa, então eu preciso colocar o wait para ele terminar de executar. Então vamos rodar aqui novamente. Deixa eu rodar de novo aqui. E agora ele vai demonstrar aqui que eu não tenho a tabela ali, partner, ela não existe. Eu posso pedir antes de ser executado aqui para ele criar todo o schema. Ele cria para mim automático, então eu faço assim, o rm.schema.refreshDatabase. Vamos executar aqui novamente. Vou tentar um terminal novinho. Show de bola. E aqui também, sempre eu passo um tempo sem mexer com o TypeScript, e aí a gente sempre esquece do await quando tem uma promessa. Criou lá no banco de dados, né? Mas o que ele criou exatamente? estou bem curioso para poder ver o que aconteceu então vamos entrar lá no console use events select asterisco from partner que é a tabela que ele criou então ele conseguiu persistir as duas informações lá então olha que interessante. O nosso objeto, inclusive, o caso do ID, que é um objeto de valor, ele conseguiu ir para o campo corretamente. Porque nós colocamos aquele toString. Lembra aquele toString que fica lá no valueObject? O RM acabou tentando converter ele para string, então o valor foi corretamente. Então, foi isso aqui que ajudou no final das contas, mas isso aqui é um devido problema, porque nós temos que, de certa forma, fazer um mapeamento melhor disso aqui, porque na hora que a gente for fazer a consulta de volta, o refresh sempre vai matar o banco de dados. Então, vamos tentar consultar novamente aqui o partner para poder consultar. Essa aqui é uma das maneiras. Então, tem o await aqui bonitinho. Vamos fazer um console.log aqui. Vamos ver como que ele vai buscar isso para a gente uma vez que ele vai hidratar a nossa classe partner. Vendo o resultado, aparentemente está correto. Mas a gente tem que tomar um cuidado, porque como o nosso partner ID, ou qualquer entidade que a gente está criando ali, mantendo o UID, acaba sendo gerado se não passar nada, será que está correto mesmo? A gente consegue ver essa diferença fazendo antes de salvar lá, pegando aqui o ID. Vamos fazer aqui o ID antes, porque a gente vai ver aqui e comparar para ver se está correto. Então, vamos rodar aqui novamente. Vamos ver, o ID daqui de cima é o 39F2 e aqui de baixo é o 39F2. Parabéns, Luiz, você fez corretamente, está funcionando. Não, não está. Isso aqui é uma cilada que normalmente esses ORMs que trabalham com Datamapper têm. Porque quando a gente faz aqui o persist, ele mantém esse objeto na memória. Quando eu faço o find ali, passando aquele ID, opa, já tem aqui. Ele não bate no banco de dados, ele só pega o que está ali. Então, tem uma cilada. A gente vai ter que forçar aquele consultor no banco de dados. Então, antes aqui, eu vou fazer um clear. Esse clear vai limpar o nosso Unit of Work. Depois a gente vai falar mais sobre isso. Vamos ver se, de fato fato a gente tem o nosso partner inclusive eu coloquei aqui porque ele mostrou, ah tá certo então eu limpei o clear aqui ele vai devidamente fazer a limpeza eu não vou ter mais forcer essa entidade e fiz lá o meu find1. Então, olha só. O id está correto. Porém, na hora que ele carregou no banco de dados, ele só colocou o valor ali no id. Ele só colocou o valor no id. Então, aqui a gente não tem mais o objeto de valor. A gente perdeu a integridade do nosso modelo. Então, são esses tipos de adaptações que a gente tem que fazer. São essas adaptações que nós temos que garantir para que, tanto na hora de persistir, seja persistido de forma correta o nosso modelo rico, e na hora de recuperar, seja recuperado de forma correta. Então, cuidado na hora de você for fazer esse teste com o seu data mapping, se você está fazendo semelhante a mim, aplique o clear, senão você faz o find ones e você vê, opa, está corretinho, mas aqui, de fato, o que a gente está fazendo, eu limpo o cache do entity manager, o unit of, o cache do Entity Manager, o Unit of Work, no final das contas, que está trabalhando aqui por trás. Então, agora a gente tem que melhorar o nosso mapeamento relacional aqui para adaptar, para permitir que o nosso modelo, de fato, está sendo persistido corretamente, mas ele precisa ser recuperado de forma correta. Então, vamos seguir na nossa saga. É isso aí e até a próxima.