# 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