[SP-pm] DBIx::Class

[Blabos de Blebe]

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 <shonorio em 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.oliveira em 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 em 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 em bla')
>> and email = 'fulano em 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 em 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 em 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 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/20130914/67e2297a/attachment-0001.html>