Opa Solli, Se eu tivesse visto esse mail antes teria te poupado a pesquisa, mas por outro lado, você chegou na mesma solução que eu, pelo mesmo motivo.
Se estiver errado, estamos errando igual. Quando vc só precisa validar se o campo existe ou não, blz. Você pode fazer um find_or_create() ou um update_orcreate(). Mas quando vc tem mais constraints e as suas mensagens de erro precisam ser mais precisas (!?) para o usuário você acaba tendo que parsear a string de erro lançada pelo banco, que eu não sei se é padrão. Um problema nessa abordagem, é que você está sujeito a race conditions entre o momento que você consultou e o momento que você está gravando. Portanto, pode ser uma boa ideia usar transactions, que com DBIC é tranquilo também. Quanto a performance, não tenho ideia, nem parei pra pensar nisso nesse momento (protótipo), mas é uma preocupação bastante pertinente, pra dizer o mínimo. Pessoal, não sou expert em DBIC, se houver solução melhor, estamos ouvindo. []'s 2013/9/14 Solli Honorio <shono...@gmail.com> > Bom, descobri um motivo para não utilizar a abordagem que eu estava > imaginando. > > O perl não possui um sistema de Exception decente, e o DBIx::Class também > não faz nada muito avançado neste sentido. Atualmente o DBIx::Class gera um > exception simplório através do DBIx::Class::Exception, que não tem nenhuma > maneira simples de identificar o motivo do erro. > > Na solução atual eu preciso parsear o mensagem de string, mas isto tem um > problema. Cada banco de dados pode gerar uma mensagem diferente para o > mesmo problema (neste caso colisão de índice único) e aí eu preciso criar > uma enorme estrutura de parser para atender todos os bancos, ou pelo menos > a maioria (ah, que inveja do Java !!!). > > Ou seja, é melhor ser educado e fazer as perguntas corretas ao banco :D !! > > Abraços, > > Solli Honorio > > > Em 14 de setembro de 2013 15:22, Lucas Mateus < > lucasmateus.olive...@gmail.com> escreveu: > > >> Boa pergunta André. É um teste simples de fazer, que acha de >> fazer em seu SGBD preferido e nos dizer ? >> >> >> >> Em 14/09/2013, às 14:39, André Walker <an...@andrewalker.net> escreveu: >> >> > On Sat, Sep 14, 2013 at 12:44:35PM -0300, Lucas Mateus wrote: >> >> Para tornar esse processo mais rápido eu crio um campo do tipo binary >> 16 >> >> bytes e gravo o md5 (binario sem hexadecimal) do email e utilizo ele >> para >> >> consulta. >> >> Algo assim: select id from users where email_md5 = md5('fulano@bla') >> and email = 'fulano@bla'; >> >> Onde somente o campo email_md5 tem index e você tem certeza que ele >> sempre >> >> terá 16 bytes, se você tiver 1 milhão de usuários essa consulta terá um >> >> custo risório. A segunda comparação é somente para evitar colisões de >> md5 e >> >> o index é feito somente no campo email_md5. >> > >> > Será que isso é realmente necessário? Quer dizer... qual o problema de >> ter um >> > índice no campo email mesmo? De qualquer forma, você já vai ter um custo >> > computacional na função md5 (ainda que pequeno), e tenho a impressão que >> > índices em campos texto não são tão ruins assim. Talvez varie de SGBD >> pra >> > SGBD? Em PostgreSQL, por exemplo, seria relevante ter essa coluna >> email_md5? >> > >> > Att. >> > André >> > >> > =begin disclaimer >> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> > SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org >> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> > =end disclaimer >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> > > > > -- > "o animal satisfeito dorme". - Guimarães Rosa > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer