Feature

Remodelar a classe de Package e criar a nova classe File.

• Tipo: Refatoração/Nova implementação
• Depende da issue: #77.
  • Status: Totalmente.
• Branch: no final, deverá ser feito um merge para a branch version-2.

Checklist:

• [ ] Implementar feature;
• [ ] Adicionar testes;
• [ ] Atualizar docstring;
• [ ] Atualizar documentação.

Para entender melhor

A seguir as mudanças que consistem nessa issue.

• [ ] A classe File existente se tornará em um Mixin para a classe Package;
• [ ] Criar a nova classe File a qual conterá os dados sobre cada arquivo presente em um pacote (os dados selecionados serão decididos no debate dessa issue);
• [ ] Remodelar a classe Package para que possua uma lista de objetos File.
  • [ ] Criar métodos de manipulação dessa lista de objetos File (os métodos serão decididos no debate dessa issue).

Tomemos como base a requisição http://dados.ufrn.br/api/rest/dataset/discentes. Nessa requisição iremos coletar o máximo de dados possíveis sobre o pacote e os arquivos que a ele pertencem.

Dados de File

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados (os arquivos estão em resources da requisição):

Dado	Exemplo de valor
format	"CSV"
description	"Relação dos discentes de ingressantes em 2019 na UFRN."
name	"Ingressantes em 2019"
url	"http://dados.ufrn.br/dataset/554c2d41-cfce-4278-93c6-eb9aa49c5d16/resource/a55aef81-e094-4267-8643-f283524e3dd7/download/discentes-2019.csv"
created	"2019-02-28T10:39:39.841876"
last_modified	"2019-08-26T21:02:17.004565"

Os campos name, description e format seriam para conhecer melhor sobre o arquivo em si. url seria para realizar o download do arquivo. created e last_modified seriam para saber desde quando o arquivo existe e se ele já sofreu alguma mudança (possivelmente correção de erro e tals, como já teve).

Métodos de File

O acesso aos atributos não necessitaria de métodos (por exemplo os gets), pois é um padrão adotado em alguns pacotes que já vi, como df.columns que é uma variável da classe pandas.DataFrame.

Existiria o método download(), porém os parâmetros poderiam ser diferentes dos que já existem, visto que os filtros de dicionário e anos serão aplicados em Package, no vetor de File, e não diretamente em File.

Dados de Package

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados:

Dado	Exemplo de valor
version	"1.1"
resources	Lista de File
title	"Discentes"
name	"discentes"
ckan_url	"http://dados.ufrn.br/dataset/discentes"
notes	"Relação dos discentes da UFRN."
notes_rendered	"<p>Relação dos discentes da UFRN.</p>"
extras	É um dicionário com alguns extras do pacote.

Boa parte dos campos seriam para permitir que o programador conheça melhor o pacote, sendo que tem atributos "redundantes" que valeriam o debate para decidirmos se iremos colocar ou não, como: notes e notes_rendered, title e name.

Métodos de Package

O acesso aos atributos não necessitaria de métodos (por exemplo os gets), pois é um padrão adotado em alguns pacotes que já vi, como df.columns que é uma variável da classe pandas.DataFrame.

• __init(self)__: o construtor poderia receber o nome do pacote, aí seria feito a requisição que preencheria a lista de File e pegaria todos os dados necessários.
  • Deveria existir um método set_package() que receberia o nome de um novo pacote, atualizando todas as informações do objeto atual, ou seja, não retorna um novo objeto;
  • Poderia existir o erro de não encontrar o pacote desejado.
• download(): que iria baixar toda a lista de File que existem no Package;
  • Perceba que isso já exclui o atual método download_all(), pois não condiz ao comportamento atual do pacote, sendo necessário colocar esse método em outro local.
• filter(): que iria receber uma função e filtrar a lista de File, retornando um novo Package com os arquivos que satisfizessem o filtro aplicado. Esse método retorna um novo Package.
  • Existiria filtros já criados, como o de baixar dicionário ou não ou se o arquivo está dentro de um range de anos.

Métodos já existentes como print e load poderia ser adaptados, o primeiro para imprimir as informações do pacote e da lista de arquivos (fica a critério do programador decidir isso) e o segundo para dar um refresh no pacote atual que o objeto representa.

Demais funções que existem atualmente

Funções como download_packages, search_related_packages, download_all, download_packages_by_tag e download_packages_by_tag seriam realocados para as novas classes que o pacote irá ter, como um novo modelo para Tag e Group. Isso pois atualmente a classe Package pode manipular mais de um pacote ao mesmo tempo, exemplo: download_all baixa todos os pacotes, e a função dela ao final dessa issue é representar um único pacote.

Dados de Package

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados: Dado Exemplo de valor version "1.1" resources Lista de File title "Discentes" name "discentes" ckan_url "http://dados.ufrn.br/dataset/discentes" notes "Relação dos discentes da UFRN." notes_rendered "<p>Relação dos discentes da UFRN.</p>" extras É um dicionário com alguns extras do pacote.

Boa parte dos campos seriam para permitir que o programador conheça melhor o pacote, sendo que tem atributos "redundantes" que valeriam o debate para decidirmos se iremos colocar ou não, como: notes e notes_rendered, title e name.

Essa parte de imprimir pacote podemos implementar como str da classe packages. Outra é que a renderização html notes_rendered é desnecessária, além disso o name e title da API são praticamente iguais, devemos escolher uma das duas.

Dados de Package

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados: Dado Exemplo de valor version "1.1" resources Lista de File title "Discentes" name "discentes" ckan_url "http://dados.ufrn.br/dataset/discentes" notes "Relação dos discentes da UFRN." notes_rendered "<p>Relação dos discentes da UFRN.</p>" extras É um dicionário com alguns extras do pacote.

Boa parte dos campos seriam para permitir que o programador conheça melhor o pacote, sendo que tem atributos "redundantes" que valeriam o debate para decidirmos se iremos colocar ou não, como: notes e notes_rendered, title e name.

acho interessante mantermos o note, mas notes_rendered é irrelevante e escolheríamos entre title ou name, possivelmente name

Como File só é estendida para Package, não há razão para ela ser um mixin, então ela vai ser só uma classe normal que será estendida pra package.