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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
