Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrar as tabelas de “look up" (map[int]string) para o Badger (armazenamento de chave e valor) #197

Closed
2 of 7 tasks
cuducos opened this issue Nov 20, 2023 · 0 comments · Fixed by #219
Closed
2 of 7 tasks

Comments

@cuducos
Copy link
Owner

cuducos commented Nov 20, 2023

No ETL (comando transform) utilizamos alguns map[int]string para mapear coisas como código do município para nome do muncicípio, por exemplo.

Depois da implementação do Badger como cache durante o ETL (#173), o mesmo Badger pode ser utilizado para essas tabelas de código e nome de município, CNAE, países etc. Em termos de performance não deve ter um impacto grande (as consultas podem ser feitas em paralelo, pois são read-only, as escritas são poucas), e o código pode ser muito implificado.

Possível estratégia de implementação:

  • Extender newKVItem para suporte de novos sourceTypes
  • Extender o enrichCompany para suporte dos novos campos
  • utilizar o newKVitem para criar e, depois, salvar os dados das tabelas de look up no Badger no início do ETL
  • limpar código (que não é mais utilizado) relacionado às antigas tabelas de look up

Repetir o processo para:

@cuducos cuducos changed the title Migrar as tabelas de “look up" (map[int]striong) para o Badger (armazenamento de chave e valor) Migrar as tabelas de “look up" (map[int]string) para o Badger (armazenamento de chave e valor) Dec 14, 2023
cuducos added a commit that referenced this issue Apr 13, 2024
cuducos added a commit that referenced this issue Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant