[SP-pm] DBIx::Class

[Alceu Rodrigues de Freitas Junior]

Em 16-09-2013 22:34, Eden Cardim escreveu:
>
>     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.

Não é Eden. Se eu quiser fazer upsert e que tenha um desempenho maior 
vou ter que descer até o banco de dados. Dá para fazer conforme você 
demonstrou, talvez a diferença de velocidade seja desprezível, mas 
enfim... não é fútil a discussão.

>     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.

Eu não preciso vencer a discussão: vou ganhar o que com isso?

>
>     "In God we thrust: all others must bring data".
>
>
> Pornografia já? Tem menores de idade, e o próprio deus, lendo ;)

Deus não lê e-mails: ele tem um programa do Yahoo! para fazer isto para 
ele (vide Todo Poderoso). :-)

>
>     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"

Para este caso de upsert Eden! Só para este caso!
Use o contexto... não estou escrevendo uma especificação.

> Mas memcached foi espeficamente a solução que você recomendou... Agora
> que você mudou o discurso pra cache genérico, eu concordo contigo,
> genericamente.

Fato. Mas como você apontou, não precisa ser o Memcached. Pode ser 
qualquer coisa, de IPC a modperl para criar cache.

> 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.

Você já fez o suficiente dando uma referência.
Lembre-se, tem crianças lendo, então não parta da premissa de 
pré-requisitos. ;-)

> 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)

"Nojinho" do Java e similares... aquelas linguagens de programação 
corporativas, morte ao Bill Gates e todo aquele blablabla...

> 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.

Isso é assunto para outra thread. Mas até tomar água em excesso faz mal.

>     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".

Na teoria parece bonito, mas vou te dar o lado prático da moeda.

Em mainframe, os programas são em sua maioria em Cobol. Diferentemente 
de plataforma baixa, programas lentos custam mais dinheiro porque os 
fabricantes cobram, periodicamente, o valor de ciclos de processadores 
utilizados.

Então se o programa em Cobol, depois de otimizado, ainda é considerando 
lento, os programadores descem para o C.

Se com C a coisa ainda não ficou do jeito que queriam, vão mesmo para o 
Assembly.

Você chamaria isso de super-engenharia?

Para outro exemplo de "super-engenharia", vide Java Magazine 25, ano 
III, "Persistência Turbinada" que mostra que você pode abandonar o ORM 
de sua preferência e ir para o JDBC se o desempenho com o primeiro não 
estiver satisfatório.

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

Vê como eu não preciso "vencer" a discussão para ganhar alguma coisa? ;-)

[]'s
Alceu