-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modelagem e implementação dos Pontos de Coleta #9
Comments
Fernando Barreto de Almeida From: Vinicius Arcanjo @Vido e @alexandre pretendo começar o model e view do django app para os "pontos" (pontos de coleta). Vou fazer a seguinte modelagem: class PontosDeColeta(models.Model): """ id = django default id...name = models.CharField(max_length=200, default='') Será que não seria interessante colocar também no nosso DB, informações de horário de funcionamento e telefone destes estabelecimentos? Imagino que estas informações seriam interessante caso o Usuário/Carroceiro, vai fazer o deposito no lugar ele poderia saber o horário de antemão, ou até mesmo ligar para o estabelecimento para questionar alguma coisa. Talvez o telefone seja preciosismo mas imagino que se conseguissemos o horário de funcionamento e dias de funcionamento seria interessante. @Vido , eu vi que varios dos nosso registros nos pontos.sql o nome deles são "type" imagino que é informação incoerente ou incompleta. Você poderia checkar com o pessoal do PIMP para atualizar os dados? ou fornecer uma fonte confiável? Aguardo o retorno para continuar o desenvolvimento deste model e view. — Este email foi escaneado pelo Avast antivírus. |
@fernandobalm , ideia fantástica essa dos preços. Desta forma, um carroceiro poderia maximizar os lucros de acordo com o tipo de mercadoria que ele tem. Mas, em contrapartida, manter os preços e os telefones, significa que alguém deverá ser responsável por ficar atualizando (talvez mensalmente?) estes preços e telefones? Afinal, preços variam frequentmente e telefones eventualmente poderão mudar. Mas, de qualquer forma excelente ideia, acredito que poderiamos implementar como um "enhancement" em um segundo momento. Bom, acredito que parar ser mais realista e pé no chão por enquanto, vou implementar o mínimo para esta issue, e no futuro podemos acrescentar novas funcionalidades (telefone, preços, horários de atendimento) @Vido , então para este momento precisamos somente confirmar com o pessoal do PIMP, sobre esta questão dos nomes com "type" (que me parecem pontos incompletos). De antemão seria interessante se o pessoal do PIMP já sinalizasse o que seria possível de adicional eles obter destes pontos, desta maneira eu já adicionaria neste mesmo sprint. Todos de acordo? aguardo o OK para iniciar o sprint. |
@viniciusarcanjo, |
@Vido, no meu entendimento PontosDeColeta e Carroceiro sao duas aplicacoes django (database) distintos. Por isto imaginei que o mais coerente seria criar um django app para o Pontos De Coleta, pelo meu entendimento este seria um modelo tambem, o qual teria a sua view. Caso eu enterpretei algo errado me avise. Em relacao a esta modelagem, de acordo com os dados que temos no DB, a unica distincao entre ambos eh que carroceiro possui "address" e PontosDeColeta possui "type", mas conceitualmente seriam entidades/databases para propositos distintos, uma representa um Ponto de Coleta enquanto a outra representa um Carroceiro (embora tenham suas similaridades devido a nossa aplicacao simples). |
hmm @Vido, acho que entendi seu ponto relendo novamente a especificação na issue #1 . Do ponto de vista da aplicação consumer, Carroceiro e Pontos De Coleta seriam praticamente a mesma coisa, Mas, ainda sim confesso que estou confuso em relação se faz sentido a separação, apesar das similaridades. Qual sua sugestão? Valeu! @fernandobalm , você teria alguma sugestão também? |
Fernando Barreto de Almeida From: Vinicius Arcanjo hmm @Vido, acho que entendi seu ponto relendo novamente a especificação na issue #1 . Do ponto de vista da aplicação consumer, Carroceiro e Pontos De Coleta seriam praticamente a mesma coisa, Mas, ainda sim confesso que estou confuso em relação se faz sentido a separação, apesar das similaridades. Qual sua sugestão? Valeu! @fernandobalm , você teria alguma sugestão também? — Este email foi escaneado pelo Avast antivírus. |
Sobre dos Dados:Só esclarendo:
Sobre os Models:@fernandobalm, sim eu conconrdo. No mundo real existe PontosDeColeta e Carroceiro. Um é uma Organização e outro é um Individuo. Mas para quem vai usar o App, isso importa? Vou fazer uma tabelinha para comprar os dados das bases:
@fernandobalm, com relação a cirurgia traumática, as opções aqui são as seguintes:
Logo, usando o princípio YAGNI (You aren't gonna need it), não vejo motivo de se ter um model apenas para PontosDeColeta e outro apenas Carroceiro. O que vamos criar são lógicas duplicadas e tratamentos para juntar duas coisas em uma. |
@Vido, obrigado pelo esclarecimento. Vou utilizar esta issue entao para ajustar o script para inserir os pontos.sql no mesmo db do Carroceiro e como voce disse, serao diferenciados pelo type. |
@Vido e @alexandre pretendo começar o model e view do django app para os "pontos" (pontos de coleta).
Vou fazer a seguinte modelagem:
class PontosDeColeta(models.Model):
A principio estes seriam os atributos mínimos de acordo com nossos dados existentes na pasta data para os pontos.sql.
Será que não seria interessante colocar também no nosso DB, informações de horário de funcionamento e telefone destes estabelecimentos?
Imagino que estas informações seriam interessante caso o Usuário/Carroceiro, vai fazer o deposito no lugar ele poderia saber o horário de antemão, ou até mesmo ligar para o estabelecimento para questionar alguma coisa. Talvez o telefone seja preciosismo mas imagino que se conseguissemos o horário de funcionamento e dias de funcionamento seria interessante.
@Vido , eu vi que varios dos nosso registros nos pontos.sql o nome deles são "type" imagino que é informação incoerente ou incompleta. Você poderia checkar com o pessoal do PIMP para atualizar os dados? ou fornecer uma fonte confiável?
Aguardo o retorno para continuar o desenvolvimento deste model e view.
The text was updated successfully, but these errors were encountered: