[SP-pm] DBIx::Class

Marcelo Milhomem milhomem at is4web.com.br
Sat Sep 14 16:15:40 PDT 2013


Já cai em situações em que eu precisava identificar se a falha foi por 
registro duplicado ou outro problema, consegui fazer isso facil com DBI 
pra MySQL, claro que cada banco tem um retorno de erro diferente.

$dbh = DBI->connect($DSN, $self->user, $self->pass);
$dbh->{HandleError} = sub { $self->MySQLerror(@_) };
$dbh->{PrintError} = 0; $dbh->{RaiseError} = 0;

sub MySQLerror {
     my $self = shift;
     my $errno = $_[1]->err;
     if ($errno == 1062) { 
#http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html
         $_[2] = 'ERR'; #[ ... ];    # supply alternative return value
         $self->duplicated(1);
     }
     return 1;
}

Não sei se te ajuda.

Att,
Marcelo Milhomem
www.is4web.com

Em 14/09/2013 19:50, Solli Honorio 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 
> <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130914/96fc9755/attachment.html>


More information about the SaoPaulo-pm mailing list