---
# System prepended metadata

title: Melhorias de performance no Atlas 2.0
tags: [thinking_done]

---

# Melhorias de performance no Atlas 2.0
###### tags: `thinking_done`
### Problemas com a modelagem atual:

- Melhorar a performance do infoset#stats na rota de visualizacao de outro usuario
- Melhorar a performance do metodo que retorna as tags do user_generated_data no infoset
- Melhorar a performance do metodo que retorna os company-stats do infoset
- Rever como fazer a verificacao da finalziacao da exportacao para permitir que o usuario solicite a validacao de telefones





### Principais Modelos
# User: 

We will follow the decisions in here: https://docs.google.com/drawings/d/1NqO9rNUencpb9pK8i6T7vL0wV2kYWVdQWzV5aVYoQcs/edit?usp=sharing


- Relacoes:
        - ProspectingLogs -> precisa ser embeded? N sera embeded
        - PhoneValidStatus -> precisa ter relacao? On hold
        - CustomPhones -> precisa ter relacao? On hold
        - Comments -> precisa ser embeded? N sera embeded
        - Sessions -> precisa ser embeded? n precisa ser embeded
        - UserGeneratedData -> precisa ser embeded? n precisa ser embeded
    - Campos/fields:
        - exported_cnpjs/company_gov_id_in_blacklist -> precisa ser outra collection -> on hold
        - .*score.* -> precisa ser outra collection -> sera removido
        - saved_searches -> legado -> sera removido
        - integracoes -> deveriam ser uma collection separada -> sera outra collection
---
# Infosets

- 
    - Relacoes:
        - Contact -> e necessario? apagar a relacao e os dados
    - Campos:
        - hidden_columns, visible_columns, visible_column_heads, editable_columns, editable_column_heads, hidden_column_heads -> poderia ser collection separada? -> eliminar as colunas e separar em arquivos yml que o VueJS usara, a la atlas-search
        - carlist_options, complete_first_validations_results_cycle, complete_second_validations_results_cycle, total_contacts_with_identities -> remover carlist e verificar se os outros n estao sendo usados, caso n estejam, remover
        - total_contacts_with_phones -> nao deveria estar no AutoCallerList? remover
        - trash -> se temos trash, por que usamos info_set_deleted_ids? alterar para deleted e remover o infos_set_deleted_ids pq so n faz sentido
---
# Phones e Validações

We will take as base of decision this: https://docs.google.com/drawings/d/1GkKJSW7l-qEFhKIOKWLTYyy7uJU0upsn6Qk1r8KH7Fc/edit?usp=sharing

- AutoCallerList:
    - Relacoes:
        - Deveria ter relacao has_many com Phones
        - Deveria ter contagem de telefones validos, ativos, etc
        - Deveria ter relacao has_many PhoneValidations

- Phone:
    - Relacoes:
        - Deveria ter relacao belongs_to AutoCallerList
        - Deveria ter relacao has_one PhoneValidation
        - Deveria manter a relacao para Contact e para Company?

    - Campos:
        - identity_mongo_id -> procurar wtf -> remover

- PhoneValidation(?):
    - Relacoes:
        - Deveria ter uma relacao belongs_to Phone
        - Deveria ter relacao com Icompany?
        - Deveria ter uma relacao belongs_to AutoCallerList
    - Campos:
        - phone_number -> e necessario dado que ja tem relacao com o Phone?
        - last_update -> substituir por TimeStamps

#### pontos importantes:

- Calcular as metricas que usamos para o phone-validatios/phone-validated e ver se o counter cache seria o suficiente para isso


- Ver as opcoes para calcular os stats dos phone-validations:
    - map-reduce para retornar estatisticas direto do banco
    - usar map-reduce para retornar todos dos Phones e PhoneValidation e depois filtrarmos/contarmos no ruby
    - field cache que recalcula as contagens dentro do infoset e e chamado quando toda a exportacao e feita, quando a solicitacao de validacao de telefone e chamada e quando e feita a atualizacao dos status dos phone validations


---
# Misc
#### Conferir se o whenever esta sendo rodado apos o deploy

#### Add timestamp em tudo

- Sera criada uma nova collection CnpjExcluded:
    -  fields:
        - array de cnpjs
        - id
        - user_id
        - excluded_reason
- Na query pegaremos todos os array de cnpjs de acordo com o user_id e usar distinct para evitar informacoes duplicadas

