Recuperar informações sobre Catadores

[Vido]

Criar um recurso que seja capaz de recuperar um catador específico.

Exemplo:

Algumas chaves podem ser usadas:

• Hash do catador
• Pk do catador

Então atualmente temos esses campos: id, name, phone, address, latitude, longitude
Mas olhando pelo mockup, vamos precisar também:

Fotos do catador
Descrição do Perfil
Tipo de material que ele recolhe
Comentários

Temos quer ver como vamos gerenciar isso.
Se o catador é um usuário, ou se o catador é tipo uma wiki.

Eu imagino que não precisamos passar todos o dados.
Só precisamos do tipo (catador, coperativa, etc...), posição, nome, endereço.
Acho que isso já basta;

A API pode retornar tudo o que tem na base.
Depois precisamos pensar em algum tipo de filtro por posição.

/coleta/                               # Sem filtro, retorna tudo
/coleta/?type="coperativa" # Não temos nada isso
/coleta/?type="catador"
/coleta/?city="sao paulo"

[viniarck]

Apos a aprovacao do pull request eu gostaria de discutir todos os parametros para que o Model e View fiquem consistente e para que possamos ter todos os testes de integracao 100% funcionais.

[viniarck]

Gostaria de definir os atributos do carroceiro. Mas, antes disso preciso que as seguintes questoes sejam respondidas:

1. @Vido, na nossa database, existem carroceiros que possuem mais de um registro, por ex:

("Denilson", "954167784", "Rua Inacio Pereira da Rocha n 25", -23.5586191, -46.6872522);
("Denilson", "954167784", "Rua Cardeal Arco Verde 1000", -23.5577372, -46.6817867);

Você sabe me dizer se isto foi um erro ou se realmente um carroceiro poderia cadastrar mais que um endereço? Por exemplo, o Denilson, cadastrou o endereço de duas localizações onde ele pode ser encontrado?

Após responder a primeira questão, precisamos definir o que deverá ser "UNIQUE" no nosso DB, porque não podemos permitir que carroceiros tenham identidades confundidas. Como vocês podem ver no model que eu fiz, o nosso atual "pk" continua sendo um id (automaticamente o django insere o id no database basta ver no "manage.py sqlall"), mas, na pratica precisos de outros atributos unique, afinal como eh que a "consumer application"/API client vai poder alterar (PUT/DELETE) um carroceiro se a aplicacao nao sabe como "localizar" um carroceiro? certo? A aplicação precisa saber de identificadores para realizar certas operações. Por isto que eu tinha pensando no telefone (inluindo até 15 dígitos conforme pode ser visto no código).

Claro, nem sempre a aplicação precisaria de um "id" para encontrar localizadores, por exemplo, no caso de uso onde a aplicação estaria procurando por qualquer carroceiro mais próximo de uma latitude, longitude X, Y basta procurar na "lista de carroceiros e verificar qual eh o mais próximo. Mas, conforme mencionado anteriormente, em operações de PUT/DELETE eh necessário a aplicação saber o que é UNIQUE para chegar até o carroceiro correto e efetuar a operação.

Caso não for seguir com o telefone como atributo unique, precisamos definir outro atributo. @Vido, seria possível o pessoal do pimp atualizar o DB com CPF ou RG dos carroceiros? Assim este poderia se tornar unique e o phone nao seria mais unique.

Aguardo seu retorno para terminar o desenvolvimento do Model e View dos Carroceiros.

Obrigado pelo feedback pessoal! Bora lá!

[fernandobalm]

Prezados,

A chave única não poderia ser um identificador do próprio sistema? Um id que identificaria os carroceiros apenas no sistema e de que eles teriam conhecimento? Ou será que isto seria inviável e eles perderiam este identificador?

Caso não possa ser, creio que é interessante tomar algum cuidado com RG e CPF, pois o RG não é único nacionalmente, precisando de órgão emissor e UF para ser único, além de ser outro documento para estrangeiros (imagino que possam existir imigrantes carroceiros) e o CPF de algumas pessoas mais velhas era compartilhado entre homens e mulheres (era o mesmo para ambos), além de menores eventualmente poderem usar o dos pais e de que nem todas as pessoas (provavelmente principalmente nem todos os carroceiros) têm CPF.

No caso de um id interno creio que seria necessária uma funcionalidade de busca do carroceiro a partir de informações significativas no mundo real, como nome, endereço, etc.

Caso o carroceiro possa ter mais de um endereço, como dito pelo Vinícius, creio que o banco de dados está desnormalizado. Talvez fosse interessante explodir a tabela em duas, uma para os dados do carroceiro em um só registro e outro para os seus endereços, que poderiam estar em mais de um registro. Seria 1 para N. Talvez o mesmo valha para telefones.

Qualquer questão basta falarem.

Abraços!

Fernando Barreto de Almeida
mailto: [email protected]
http://fernandobalm.xpg.com.br
Telefone: 55 - 11 - 33410224
São Paulo - SP - Brasil

From: Vinicius Arcanjo
Sent: Tuesday, November 3, 2015 7:51 PM
To: PimpAPP/pimpapp-api
Subject: Re: [pimpapp-api] Recuperar informações sobre Catadores (#1)

Gostaria de definir os atributos do carroceiro. Mas, antes disso preciso que as seguintes questoes sejam respondidas:

1. @Vido, na nossa database, existem carroceiros que possuem mais de um registro, por ex:

("Denilson", "954167784", "Rua Inacio Pereira da Rocha n 25", -23.5586191, -46.6872522);
("Denilson", "954167784", "Rua Cardeal Arco Verde 1000", -23.5577372, -46.6817867);

Você sabe me dizer se isto foi um erro ou se realmente um carroceiro poderia cadastrar mais que um endereço? Por exemplo, o Denilson, cadastrou o endereço de duas localizações onde ele pode ser encontrado?

Após responder a primeira questão, precisamos definir o que deverá ser "UNIQUE" no nosso DB, porque não podemos permitir que carroceiros tenham identidades confundidas. Como vocês podem ver no model que eu fiz, o nosso atual "pk" continua sendo um id (automaticamente o django insere o id no database basta ver no "manage.py sqlall"), mas, na pratica precisos de outros atributos unique, afinal como eh que a "consumer application"/API client vai poder alterar (PUT/DELETE) um carroceiro se a aplicacao nao sabe como "localizar" um carroceiro? certo? A aplicação precisa saber de identificadores para realizar certas operações. Por isto que eu tinha pensando no telefone (inluindo até 15 dígitos conforme pode ser visto no código).

Claro, nem sempre a aplicação precisaria de um "id" para encontrar localizadores, por exemplo, no caso de uso onde a aplicação estaria procurando por qualquer carroceiro mais próximo de uma latitude, longitude X, Y basta procurar na "lista de carroceiros e verificar qual eh o mais próximo. Mas, conforme mencionado anteriormente, em operações de PUT/DELETE eh necessário a aplicação saber o que é UNIQUE para chegar até o carroceiro correto e efetuar a operação.

Caso não for seguir com o telefone como atributo unique, precisamos definir outro atributo. @Vido, seria possível o pessoal do pimp atualizar o DB com CPF ou RG dos carroceiros? Assim este poderia se tornar unique e o phone nao seria mais unique.

Aguardo seu retorno para terminar o desenvolvimento do Model e View dos Carroceiros.

Obrigado pelo feedback pessoal! Bora lá!

—
Reply to this email directly or view it on GitHub.

---

Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus

[viniarck]

Excelente observação @fernandobalm sobre a questão do CPF/RG.

Bom, na prática já temos o id que é unico (PK) e auto increment, então cada carroceiro vai continuar com ele, entretanto o atributo phone a partir da próxima entrega vai deixar de ser unique. Além disso, acredito que podemos deixar tudo do jeito que esta e no momento não incluir CPF nem RG para evitar complicações.

Então as operações de PUT e DELETE, serão necessário o ID do catador, que poderá ser obtido através da list em GET /carroceiro/, e as operações de PUT e DELETE (/carroceiro//). Entretanto, para realizar a modificação sobre este ID vou colocar um usário admin de autenticação.

Então na prática ficaria assim:

Qualquer operação para POST/PUT/DELETE de um carroceiro vai ser necessário ter autenticação, desta forma, somente quem é autorizado irá poder modificar o carroceiro. No futuro, podemos implementar usuário e senha para os Carroceiros e eles mesmos poderão utilizar PUT/DELETE. Mas, no momento será tudo através do Admin que provavelmente ficará controlado pelo pessoal do PIMP.

Deste jeito praticamente todo problema de coerência esta resolvido, porque mesmo se existir "2 Denilson", caso um destes precisar ser modificado o mesmo deverá entrar em contato com o PIMP, confirmar seu endereço etc e o pessoal do PIMP faz as alterações (pelo menos por enquanto)

Todo mundo de acordo? caso positivo eu posso começar a resolver a issue #8 e posteriormente voltar para esta issue #1 e continuar discutindo a segunda parte que seria os filtros para os pontos de coleta.

Aguardo o retorno de vocês para começar o proximo sprint! Obrigado!

[Vido]

@viniciusarcanjo ,

Sobre o caso do catador "Denilson". Acredito que seja um erro. Pois ambas as ruas ficam na região de Pinheiros/Vila Madalena e são próximas.

Com relação aos documentos. Acredito que o povo do Pimp não tem esses dados. Talvez seja possível conseguir os RGs, dificilmente os CPFs (pois provavelmente nem existem).
Talvez estes não são dados importantes para a aplicação. Já que não existem considerações comerciais/jurídicas/fiscais etc... Acredito que o PK do Django já esteja de bom tamanho.

Com relação a endereços e telefones. Não há garantias que eles são dados escritos na pedra.
Eu acredito que devemos focar em flexibilidade. Então o Model Carroceiro deveria ter um ManyToManyField para o "Model Telefone" e "Model Endereço"

Como o @fernandobalm mencionou, O 'cliente/consumidor' quer procurar o 'serviço' Carroceiro mais conveniente. Então teremos filtros por tipo de material, localização, se é catador ou ecoponto etc...

Como o @viniciusarcanjo. As operações read-only podem ser abertas. Mas as operações write devem ser protegidas. Neste momento qualquer segurança serve.