[SP-pm] DBIx::Class

[Eden Cardim]

>>>>> "Alceu" == Alceu R de Freitas <glasswalk3r em yahoo.com.br> writes:

    Alceu> Solli, Recentemente comecei a fazer alguns testes com
    Alceu> TryCatch e até o momento me pareceu bastante satisfatório,
    Alceu> mas você pode se pegar criando várias classes de exceção.

Um convite pro overengineering.

    Alceu> Se você quiser ser realmente eficiente com o banco, acho
    Alceu> que vai ter que abandonar o DBIx::Class: se você criar uma
    Alceu> stored procedure no banco de dados você pode criar uma
    Alceu> função de "upsert" (atualiza se existe, insere se não) sem
    Alceu> ter que retornar dados para a camada do DBIx::Class e da
    Alceu> sua aplicação e poderá capturar a exceção com precisão no
    Alceu> banco (dependendo do banco que você for utilizar, claro).

Overengineering e otimização prematura ao mesmo tempo. E mesmo pra
otimizar, não precisa largar o DBIx::Class, se (e repito, *se*) você
cair num caso onde você precisar chegar nesse nível de otimização, é
só sobrecarregar as partes certas do código.

    Alceu> Ou então fazer um esquema de cache experto (Memcached?)
    Alceu> para os registros já inseridos no banco, isso tornaria a
    Alceu> coisa toda mais eficiente.

Mais eficiente e mais errada, sujeito a race conditions insolúveis.

    Alceu> De qualquer forma, o DBI tem o método err()
    Alceu> (http://search.cpan.org/~timb/DBI-1.628/DBI.pm#err) para
    Alceu> retornar um código numérico... claro que você teria que
    Alceu> criar de antemão uma tabela com os códigos de cada banco de
    Alceu> dados que você quer que sua aplicação suporte. Como
    Alceu> DBIx::Class usa DBI, talvez você consiga ter esta mesma
    Alceu> informação.

E porque isso é mais fácil ou rápido do que usar algo que é
naturalmente portável entre todos os backends que suportam SQL: uma
consulta antes do insert?

-- 
Eden Cardim -- Insolide Soluções de TI Ltda.
+55 11 9644 8225
http://insoli.de