Adicionar a capacidade de pupolar o campo related_articles #302
Conversation
…igos relacionados.
… retorna .json e request.response
| if (article.type == "correction" | ||
| or article.type == "retraction" | ||
| or article.type == "addendum"): |
There was a problem hiding this comment.
sugestão, mas não precisa mudar por causa disso
article.type in ['correction', 'retraction', 'addendum']There was a problem hiding this comment.
me corrijo, se isso tiver melhor desempenho, sim mudar, pois a produção tem processado uma qtd imensa de pacotes
| article.related_articles = [ | ||
| models.RelatedArticle(**related_dict)] |
There was a problem hiding this comment.
talvez prever que um documento no decorrer do tempo possa ter mais de uma errata
There was a problem hiding this comment.
Sim para esse caso seria:
if article.related_articles:
article.related_articles = article.related_articles + [
models.RelatedArticle(**related_dict)
Ou seja, eu incremento a lista de related_articles caso ela já exista!
There was a problem hiding this comment.
@gitnnolabs mas acho que há um engano aqui... pois me parece que está sendo atualizado o related_article com os dados que ele já tem e não com os dados do documento relacionado com ele.
Tem que haver atualização de related_articles no documento que está sendo processado e no documento que está criando o vínculo.
| # # sps_package = SPS_Package(et.XML(xml)) | ||
| # resp = requests.get('http://www.scielo.br/j/jbchs/a/Z6mnK3PjKhDZtHJQJYPzxpw/?lang=en&format=xml', verify=False) | ||
|
|
||
| sps_package = SPS_Package(et.XML(resp.content)) |
There was a problem hiding this comment.
isso pode levantar exceção, certo?
| sps_package = SPS_Package(et.XML(resp.content)) | ||
|
|
||
| for related_dict in sps_package.related_articles: | ||
| if _update_related_articles(related_dict): |
There was a problem hiding this comment.
me parece que aqui deveria incluir o parâmetro pid v3 do documento que está sendo processado
| @@ -352,6 +358,43 @@ def _get_order(document_order, pid_v2): | |||
| except (ValueError, TypeError): | |||
| raise InvalidOrderValueError(order_err_msg) | |||
|
|
|||
| def _update_related_articles(related_dict): | |||
There was a problem hiding this comment.
incluir o parâmetro pid v3 do artigo que contém related_articles
| or article.type == "addendum"): | ||
| xml = fetch_document_xml(document_id) | ||
| _get_related_articles(article.doi, xml) | ||
|
|
There was a problem hiding this comment.
@gitnnolabs Me parece que o PR está incompleto e incorreto
Pelo que entendo estamos resolvendo a situação:
documento A
documento B1
documento B2
No documento A, há no xml:
{
"doi" : "10.1590/S0103-50532006000200015",
"related-type" : "corrected-article",
},
{
"doi" : "10.1590/S0103-50532006000200007",
"related-type" : "corrected-article",
}que são respectivamente dados de B1 e B2.
Este PR deve fazer o seguinte
- no artigo A sendo processado, deve-se incluir o campo related_articles que deve conter
{
"ref_id": pid v3 do documento B1 a ser descoberto procurando pelo seu doi,
"doi" : "10.1590/S0103-50532006000200015",
"related-type" : "corrected-article",
},
{
"ref_id": pid v3 do documento B2 a ser descoberto procurando pelo seu doi,
"doi" : "10.1590/S0103-50532006000200007",
"related-type" : "corrected-article",
}- Para cada documento relacionado, ou seja, B1 e B2, fazer a inclusão do campo related_article, mas o conteúdo seria:
{
"ref_id": pid v3 do documento A (já sabido)
"doi" : doi do documento A (já sabido),
"related-type" : article_type do documento A,
}, There was a problem hiding this comment.
@robertatakenaka não realizei a inclusão dos dados na errata que no exemplo seria o documento A, pois na interface do site, já contém a mensagem dessa relação.
Mas pensando melhor você tem razão, dessa forma mantemos na base de dados a relação de ida e volta:
['errata', 'retração', 'adendo'] <-> documento
Esse PR está contemplando somente:
documento -> ['errata', 'retração', 'adendo']
Agora com essa alteração, suspeito que removemos do packtools geração da caixa de errata quando existir a tag related-articles, correto?, para que o site fique responsável por montar a caixa tanto no documento que corrige(errata), quando no documento corrigido(artigo).
There was a problem hiding this comment.
@gitnnolabs são dois ou 3 pontos diferentes
- me parece que o PR apesar de pensar na inclusão de dados apenas nos documentos B1 e B2 ainda assim está inserindo dados incorretos. Pela minha revisão, pelo que entendi do código, em related_articles está sendo incluído os dados de B1 em B1 e dados de B2 em B2
- Esquece questão de interface, pensa só na questão de relacionar um registro com o outro, já que este repositório é o do airflow
There was a problem hiding this comment.
-
Parece-me que tem razão.
-
Sim, entendi isso estava com o contexto do site
… resolve um bug na relação, adiciona a unicidade entre as relação para contemplar reprocessamento e ou mais de um relacionamento.
O que esse PR faz?
Adicionar a capacidade de pupolar o campo related_articles #301
Onde a revisão poderia começar?
Por commit.
Como este poderia ser testado manualmente?
Necessário ter um instância local e rodar a DAG: sync_kernel_to_website
Algum cenário de contexto que queira dar?
Para ter efeito essa mudança é necessário que o kernel recebe uma alteração na lista de /changes para os artigos de errata, adendo e retratação, para garantir que os periódicos sejam atualizados
Screenshots
N/A
Quais são tickets relevantes?
#301 e scieloorg/opac#2052
Referências
N/A