[SP-pm] DBIx::Class

Renato Santos renato.cron at gmail.com
Sat Sep 14 18:21:45 PDT 2013


Poxa..

Eu já tratei esses erros e geralmente um $@ =~ /nome-de-pk-ou-uniq/ e isso
já basta. Não é toda hora, pra não dizer que, apps mudam de banco.

Ao menos que você esteja fazendo algo bem simples que não use funções
específicas de nenhum, você sempre vai ter estar em um banco que diz qual o
nome do unique que deu erro
On Sep 14, 2013 10:07 PM, "Marcio - Google" <marciorp at gmail.com> wrote:

> Solli++++++++
>
> > 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.
>
> Vou dormir mais tranquilo, já tava começando a achar que meu QI era muito
> pequeno para usar Perl, principalmente no que diz respeito a tratamento de
> exceções/erros.
>
> Isso é o que mais patino. Tem coisas que não consigo tratar e não tem
> acordo.
>
> [...]'s
>
> Marcio
>
> ========================================
> ########### Campanha Ajude o Marcio! ###########
> http://sosmarcio.blogspot.com.br/
> http://www.vakinha.com.br/VaquinhaP.aspx?e=195793
> ========================================
> Em 14/09/2013 18:56, "Solli Honorio" <shonorio at gmail.com> escreveu:
> >
> > 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.oliveira at 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 <andre at 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 at bla')
> and email = 'fulano at 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 at 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 at 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 at 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 at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130914/60908b09/attachment.html>


More information about the SaoPaulo-pm mailing list