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

[Blabos de Blebe]

Opa,

Valeu pra mim e essas são as minhas conclusões, pessoais e intransferíveis:

Do meu ponto de vista, o *meu* código precisa lidar com os dois casos.

1) Erros. Situações previstas, como email inválido, email já em uso, etc.
Nesses casos eu verifico antes, e tenho condições de devolver uma mensagem
clara para o usuário: "O email informado não é um email válido",
independente da camada de baixo.

2) Exceções. Situações não previstas. Nesse caso eu tenho que capturar a
exceção e se eu não sei de antemão que tipo de treco vai vir, eu ainda
posso logar isso pro sysadmin *E* mostrar pro usuário algo como "Ocorreu um
erro inesperado, tente novamente em alguns minutos".

Um sistema de exceções mais elaborado, também não me pouparia de fazer a
verificação antecipada, a não ser que o DBIC implementasse um conjunto de
classes de exceção padrão entre todos os bancos.

Isso no caso de dados violando constraints, mas e no caso de o usuário
fornecer um email inválido? Eu ainda tenho que passar um Email::Valid da
vida, ou o meu View que envia os emails de ativação de cadastro, vai
explodir com uma Exception!

Opa, blz, o view lançou uma exception. Mas o usuário foi inserido no banco?
Volto o usuário para o form de cadastro? Mas aí o username já estaria
preenchido? Deixo ele preencher um novo email? Mas o email não é chave
candidata? Poderia dar colisão novamente? E outra mensagem de erro?
Rollback de todas as ações?

Enfim, se eu validar tudo antes, eu tenho como saber antes de tocar no
model e realizar qualquer ação de cadastro. Porque não é só o banco que
pode ter constraints violadas, mas as minhas regras de negócio, são
constraints também. Além disso eu posso ter ações disparadas em cascata que
podem ser difíceis de desfazer se o apenas o último elo da cadeia der pau.

Desperdiço as constraints do banco? Não. Uso-as como redundância. Deixo a
validação para uma única camada onde eu tenho e sempre terei total
controle, usando até transactions se eu achar que devo.

[]'s


2013/9/17 Solli Honorio <shonorio em gmail.com>

> 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
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130917/9a836797/attachment-0001.html>