Corrige lookup builders, melhora dinamismo e inclui N na aba de filtros#718
Conversation
- Em algum momento, esse tipo de estrutura pode virar modelo/campo
- Útil para decidir quais tipos devem ser incluídos na build
- Necessário para o campo keyword no índice
- Obtém chaves para enriquecer lookups
- Útil para a nova função de mostrar N associado ao campo
- Incorpora novos campos que compõem lookup
pitangainnovare
changed the title
| "journal": _("Journal"), | ||
| "metadata": _("Metadata"), | ||
| "other": _("Other"), | ||
| "raidregistry": _("RAID Registry"), |
There was a problem hiding this comment.
Será que não ha um jeito de colocar colocar as tags "trans" nas opções no template? Assim a gente só colocaria as traduções nos arquivos .po
There was a problem hiding this comment.
O _() já consulta as traduções dos arquivos .po.
Tudo que se refere a display transform eu diria que precisaria virar um modelo, no futuro e fora do contexto deste PR. Por exemplo, esses dois casos que entraram eu só percebi depois de termos mais dados no servidor.
Esse display transform é usável na conf do DataSource, fazendo com que esses valores sejam apresentados de maneira melhor nos filtros (o mesmo serve para converter scielo para SciELO, então, não se trata apenas de tradução).
Caso eu tenha entendido errado ou não respondido bem o suficiente, por favor, me avise.
| def count(self) -> int: | ||
| @staticmethod | ||
| def clean_boolean_value(value): | ||
| normalized = normalize_boolean(value) |
There was a problem hiding this comment.
Chamar str no bool não resolve?
normalized = normalize_boolen(value)
return str(normalized) if normalized else ""out:
"True"
"False"
""
There was a problem hiding this comment.
Há alguns casos particulares que precisam ser analisados: 0, 1, "true", "false", True, False, "Sim", "Não", "Yes", "No", etc. Mais pra frente, podemos pensar melhor em como ter o clean_boolean mais robusto ou mesmo simplificá-lo.
|
a modificação de incorporar o N associado a cada faceta poderia ter sido feito em outra Pull Request |
| "document_types": {"type": "keyword"}, | ||
| "document_languages": {"type": "keyword"}, | ||
| "open_access_values": {"type": "keyword"}, | ||
| "open_access_statuses": {"type": "keyword"}, |
There was a problem hiding this comment.
ta correto statuses?
There was a problem hiding this comment.
Sim, costuma-se aceitar statuses como plural de status.
2 participants
O que esse PR faz?
A tarefa iniciou tratando o builder do lookup de source, que apresentava nomes relacionados a publishers entre os valores gerados. Como solução, passou a ser possível definir quais campos são úteis para popular os valores do lookup de source. Por padrão, entende-se que devem ser considerados apenas sources dos tipos
journaleconference.Como essa história está diretamente ligada ao reprocessamento dos lookups, optou-se também por implementar melhorias no dinamismo desses seletores. O sistema já possuía algum dinamismo entre campos diferentes de lookup, mas ainda não havia cruzamento entre campos lookup e campos não lookup. Por isso, os dados gerados pelos builders de lookup foram enriquecidos, permitindo aplicar esse dinamismo também nesse cenário.
Por fim, aproveitou-se a alteração para incorporar o N associado a cada faceta, permitindo que as opções exibidas nos filtros indiquem também a quantidade de documentos relacionada a cada valor. O PR também atualiza as fixtures básicas e os testes correspondentes.
Onde a revisão poderia começar?
search_gateway/lookup/base.py— utilitários (collect_document_metadata,clean_boolean_value,iter_clean_boolean_values) e o serviço de build.search_gateway/lookup/builders/{source,publisher,funder,institution}.py— enriquecimento dos lookups.search_gateway/service.py—_build_lookup_dependency_filterse o_search_lookup_optionsrecebendofilters(dinamismo).search_gateway/option_normalization.py—normalize_optionbuscando o campo de contagem.search_gateway/templates/.../widgets/{checkbox_multi,lookup}.html,static/.../js/filter_form.js,static/.../css/filter_sidebar.css.search_gateway/fixtures/datasources.json— configuração dedependency_filterspor campo.Como este poderia ser testado manualmente?
silver_scientific_productionesteja populado no OpenSearch.SEARCH_GATEWAY_LOOKUP_SOURCE_TYPES(default:journal,conference) conforme o cenário.python manage.py build_lookup_indices(use--lookup-index KEY=INDEXou apague os índices existentes, pois o comando não sobrescreve índices já criados).python manage.py loaddata search_gateway/fixtures/datasources.json core/fixtures/pages.json.Screenshots
Tela que mostra o número de registros representando um campo no filtro
Quais são tickets relevantes?
#717 e #711
Referências
N/A