[SP-pm] Resumo do que eu aprendi com a thread 'DBIx::Class'

Solli Honorio shonorio at gmail.com
Tue Sep 17 06:31:10 PDT 2013


Contextualização

A minha dúvida era se eu poderia, ou melhor, se seria uma prática aceitável
viver perigosamente com o banco de dados para ganhar alguns mili-segundos.

Conheço o mantra de não fazer otimização antecipada, mas pareceu lógico
evitar uma operação visto que o banco já está cuidando disto para mim.

Resultado da pergunta :

Quem brinca com merda, fedido ficará

Usando a analogia do Edenc, não é porque você está num ambiente seguro que
significa que você precisa abusar da segurança. O protocolo de segurança
envolve também comportamento seguro.
Neste caso, eu estaria apostando todas as minhas fichas de uma parte
importante do sistema para um comportamento do qual eu não tenho controle.
Apesar de hoje a constraint estar configurada, não impede que num futuro
algum DBA desative a constraint e quebre todo a minha segurança de viver
perigosamente confiando nos outros.

Então, como comportamento seguro, no caso de sistema, envolve *validar* *
sempre* se os dados estão qualificados para irem para o banco de dados.


Exceções as exceções

Sou muito fã da ideia (técnica) de tratar error por exceções. E isto tem
hora que atrapalha, ou melhor, precisa ser melhor colocado.

Eu gostaria muito que o Perl tivesse um sistema de exceções do tipo do
Java, C#, muito mais porquê os profissionais destas linguagens já carregam
a necessidade de fazer algo baseado em exception caso não ocorra da maneira
aguardada. Eu odeio esta história de retornar código de erro tipo ( say
"error" if funcao() >0).

Mas o fato é que Perl não tem nada (out-of-box) parecido com o que eu acho
boas práticas, e então preciso me adequar a isto, ou colaborar com código.
Neste momento da minha vida  não posso adequar o DBIx::Class aos meus
sonhos de exceções, mas a thread também mostrou que eu não preciso dela
como eu cheguei imaginar. No final posso dizer que sobre o assunto de
'erro', eu os classifico como :


Comportamento de exceção

Para mim, comportamento de exceção é quando ocorre um erro fora da minha
esfera de atuação e eu não tenho motivo, ou meios, de resolver este
problema. No caso do DBIx::Class, estou atribuindo várias atividades a esta
camada (como acessar um banco do qual eu não sei qual é - onde envolve
desde validar usuário e senha até o driver do banco, acessar uma tabela que
eu acho que sei qual é). A qualquer momento o banco poder ficar
indisponível, alguém pode alterar a senha do usuário, um dba pode alterar o
nome da tabela e/ou campo que estava mapeado pelo ResultSet. Todas estas e
outros tipos de erro é algo do qual que não vou conseguir resolver na minha
esfera, no máximo posso capturar este erro e jogar num log e torcer que
algum sysadmin leia o log ou simplesmente explodir na cara do usuário.

Com isto em mente, a discussão me ajudou num outro item que eu estava
martelando, onde colocar um agente de log no Model.

Cheguei a conclusão que este log dever ficar no Controller.


Comportamento de erro

Erro para mim passou ser aquilo que eu desejo de um dado e sei que ele
poder estar errado. Então se estou lidando com os dados de um formulário,
eu tenho condição de saber que tipo de comportamento estes dados devem ter
e por isto consigo validar. Se estes caras não estão dentro do que eu
conheço como válido, então cabe a mim tentar resolver o problema, se não
conseguir cabe a mim gerar ums exceção.

Obrigado a todos pelas informações e espero que tenha sido tão bom para
vocês como foi para mim.

Abraços,

Solli Honorio

-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130917/102ee487/attachment.html>


More information about the SaoPaulo-pm mailing list