[SP-pm] DBIx::Class

[Blabos de Blebe]

Opa,

> Ah, mas que mal humor... Se você aparecer no próximo ES te pago uma
cerveja de
> qualidade pra ver se melhora. ;)

Vale pra qualquer mal humorado?

[]'s


2013/9/16 Eden Cardim <eden em insoli.de>

>
> Concordo com todos os pontos, exceto o 1.4: DBI e DBIx::Class vão estar
>> sujeitos ao mesmo problema. Eu não manjo muito de stored procedures em
>> outros bancos, mas no Oracle consigo ter controle granular de transação,
>> então não vejo este problema que você levanta.
>
>
> Qual parte de *a depender do caso* não ficou clara? E não, tanto o DBI
> quanto o DBIx::Class não excluem a possibilidade de se usar SPs, estou
> repetindo isso durante a thread inteira e você insiste em trazer isso de
> volta. Não é uma briga DBI vs SPs, a questão é que discutir sobre SPs com
> quem ainda está cadastrando usuários é um exercício em futilidade.
>
> Que bom que você se deu ao trabalho de ajudar os monges mais novos! É
>> muito chato quando você escreve respostas achando que todos devem concordar
>> com você sem um racional!
>>
>
> Não compreendo a tua retórica... 2 parágrafos atrás a reclamação era de
> pedanteria, agora é transferência de ônus da prova? Quando as pessoas
> apelam pra esse tipo de retórica inconsistente, geralmente é uma tentativa
> de *vencer* a discussão e não de enriquecê-la.
>
>
>> "In God we thrust: all others must bring data".
>
>
> Pornografia já? Tem menores de idade, e o próprio deus, lendo ;)
>
>
>>
>>
>>  2 - *se* (repito: *se*, condicional, ramificação) for constatado que
>>> uma SP for de fato necessária como otimização (e repito, sãos raros os
>>> casos) somente aí você sobrecarrega as partes relevantes das classes
>>> envolvidas e chama a tua SP lindamente otimizada, mas só no ponto em
>>> que estiver lento, não precisa arrancar o DBIx::Class inteiro.
>>>
>>
>> Eu não me lembro de ter dito para arrancar o DBIx::Class inteiro... onde
>> foi que eu escrevi isto mesmo?
>>
>
> http://mail.pm.org/pipermail/saopaulo-pm/2013/020344.html
> Pra ser mais exato: "Se você quiser ser realmente eficiente com o banco,
> acho que vai ter que abandonar o DBIx::Class"
>
>
>> Cache != Memcached
>>
>> Eu sei que todo mundo gosta do Memcached e acha bonito (eu incluso) mas
>> para ter/usar cache existem N estratégias disponíveis...
>
>
> Mas memcached foi espeficamente a solução que você recomendou... Agora que
> você mudou o discurso pra cache genérico, eu concordo contigo,
> genericamente.
>
> Não, eu não lembrava mesmo do e-mail original do Solli. Fiquei com
>> preguiça de procurar também. Mas realmente não te salva de fazer a
>> consulta, exceto claro, se você capturar a exceção que o banco vai gerar
>> quando tentar inserir o e-mail de novo.
>
>
> Mas pô, você não lembra do email original, nem dos emails que você mandou,
> nem dos que eu mandei... Agora quem tá com preguiça sou eu.
>
>
>  1 - Não é tão rápido assim (a resolução da pilha é particularmente
>>> lenta, em qualquer linguagem)
>>>
>>
>> Tem alguma referência que mostre isto? Eu não tenho a menor ideia mas
>> gostaria de entender melhor.
>>
>
> O verbete sobre Exception Handling no wikipedia é uma boa introdução, mas
> existem pré-requisitos de conhecimento que não cabem nessa thread, por isso
> vai ficar como exercício ao leitor.
>
> Isso é um pouco de ranço, não? Exceções é algo que sinto bastante falta no
>> Perl simplesmente porque lidar com $@ é meio que um saco.
>>
>
> Não é, o $@ pode ser qualquer tipo de escalar, inclusive um objeto ou
> coderef, o que permite que você implemente as mais diversas estratégias de
> excessões (inclusive as detalhadas no verbete da wikipedia mencionado
> acima). É verdade que não tem um sistema específico pré-implementado
> "out-of-the-box", mas com o mesmo volume sintático você consegue obter
> níveis de expressividade similares ao do Java. Mas é verdade que é uma
> questão particular minha não gostar de excessões, não por "ranço" (seja lá
> o que isso signifique nesse contexto) mas porque na minha visão elas são um
> convite pra violação do princípio de menor conhecimento (também conhecido
> como Law of demeter) e toda a super-engenharia que acompanha e foi
> demonstrada nessa thread.
>
>
>>
>> 1 - É difícil ter desempenho superior sem sacrificar alguma coisa, como
>> abstração ao banco de dados. Geralmente uma solução híbrida funciona melhor
>> do que tentar procurar pela bala da prata.
>>
>
> Geralmente "solução híbrida" é expressão sinônima de "super-engenharia".
>
>
>> 2 - Não quero mais saber desta thread. O Solli que "se vire", vou ler a
>> thread sobre "o melhor dos melhores do mundo" que está mais divertida.
>
>
> Ah, mas que mal humor... Se você aparecer no próximo ES te pago uma
> cerveja de qualidade pra ver se melhora. ;)
>
> =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/20130916/edf4dd05/attachment-0001.html>