backend icon indicating copy to clipboard operation
backend copied to clipboard

refactor: Change text fields in CREATED_AT and UPDATED_AT to TIMESTAMPZ type.

Open updev-sistemas opened this issue 1 year ago • 3 comments

🤔 O que foi feito? Alterado os tipos de dados nas colunas CREATED_AT e UPDATED_AT em todas as tabelas e corrigido mapeamento nos modelos.

📗 Checklist do desenvolvedor

  • Foi testado localmente? Sim
  • Foi adicionado documentação necessária (swagger, testes e etc)? Não,

👀 Checklist do revisor

Revisor 1️⃣

  • [ ] Você entendeu o propósito desse PR?
  • [ ] Você entendeu o fluxo de negócio?
  • [ ] Você entendeu o que e como foi desenvolvido tecnicamente a solução?
  • [ ] Você analisou se os testes estão cobrindo a maioria dos casos?

🔗 Referência Issue #53

updev-sistemas avatar May 11 '24 14:05 updev-sistemas

Esse MR, altera o tipo de dado em CREATED_AT e UPDATED_AT, em cada tabela, de varchar para TIMESTAMP WITH TIME ZONE. Alterados mapeamento dos modelos, fazendo remoção de ".toISOString()" na camada de serviço.

Issue #53

updev-sistemas avatar May 11 '24 14:05 updev-sistemas

Oi, @updev-sistemas. Uma sugestão: ao invés de usar colunas temporárias, a migração poderia usar uma abordagem como:

ALTER TABLE  
    "category_supplies" ALTER COLUMN "created_at" TYPE TIMESTAMP(3) WITH TIME ZONE USING 
    TO_TIMESTAMP("created_at", 'YYYY-MM-DD"T"HH24:MI:SS.FF3"Z"')::TIMESTAMP AT TIME ZONE 'UTC';

Me parece também que as expressões regulares, sendo usadas nos testes nas cláusulas CASE , não seguem o formato dos valores que estão sendo salvos atualmente no banco, que seguem o formato especificado na ISO 8601. Considerando o teste a seguir, como exemplo, obtemos um valor falso:

SELECT 
	'2024-05-07T07:32:25.144Z' ~* '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}$';

Desta forma, todos os testes iriam "cair" no ELSE.

Além disso, vale notar que a função TO_TIMESTAMP gera valores com o fuso horário padrão definido no banco, portanto, deve-se garantir que apenas o valor do timestamp (sem o time zone) seja obtido (::TIMESTAMP) e, posteriormente, se defina o fuso de maneira explícita (AT TIME ZONE '+00:00') (no caso em questão, +00:00, dado que os valores atualmente salvos possuem "Z" ao final):

TO_TIMESTAMP(created_at, 'YYYY-MM-DD"T"HH24:MI:SS.FF3"Z"')::TIMESTAMP AT TIME ZONE '+00:00';

rafaelvargas avatar May 11 '24 16:05 rafaelvargas

ALTER TABLE  
    "category_supplies" ALTER COLUMN "created_at" TYPE TIMESTAMP(3) WITH TIME ZONE USING 
    TO_TIMESTAMP("created_at", 'YYYY-MM-DD"T"HH24:MI:SS.FF3"Z"')::TIMESTAMP AT TIME ZONE 'UTC';

Migration executada com branch DEVELOP e aplicado restore do arquivo "dev_dump.sql", em seguida, aplicada migration com a minha branch, que atualiza os campos nas tabelas.

Resultados obtidos. image

Scripts ajustados.

updev-sistemas avatar May 11 '24 17:05 updev-sistemas