[SP-pm] a minha duvida passo a passo

breno breno at rio.pm.org
Wed Nov 5 21:55:30 PST 2008


Bom, meus comentários acrescentam pouco ou nada, mas já que o Luiz
falou tanto em boas práticas, aí vão:

1) O PBP recomenda usar o módulo "Readonly" em vez do pragma
"constant". o Readonly permite que as constantes sejam interpoladas em
outras strings, além de permitir a criação de constantes dentro de um
escopo léxico específico em tempo de execução. Vale notar que nada
disso é particularmente importante para o caso em questão, mas pode
ser interessante citar aos que não conhecem as alternativas.

2) Falando em alternativas, eu gosto de seguir uma dica de boa prática
sempre que faço um here-doc, que é definir o terminador entre aspas.
Isso facilita e muito a visualização do que o desenvolvedor quer
dentro do here-doc ou, mais especificamente, se deseja que variáveis
sejam interpoladas (aspas duplas) ou não (aspas simples) do lado de
dentro (note que as aspas são especificadas apenas na definição do
terminador, não em sua utilização de fato).

Seguindo os dois comentários acima, o código ficaria:

---------------8<----------------
use Readonly;

Readonly my $QUERY => <<'END_SQL';
(...)
---------------8<----------------

Mas, melhor ainda que deixar assim, seria separar completamente as
queries SQL da programação em si. Além de não poluir o código, o DBA
pode modificá-las e otimizá-las (e o exemplo dado sugere essa
necessidade) sem se preocupar com o código Perl. Módulos como o
SQL::Library permitem que isso seja feito facilmente. O código Perl
ficaria mais ou menos assim:

---------------8<----------------
use DBI;
use SQL::Library;

my $sql_lib = SQL::Library->new( { lib => 'minhasqueries.sql' });

sub my_database_sucks_and_i_cant_code {
   my ( $dbh, $alvo ) = @_;
   return -1 unless $dbh;
   return -2 unless $alvo;

   my $row = eval {
     $dbh->selectrow_hashref( $sql_lib->retr('meu_select'),
                                           undef, $alvo )
   };
   die $dbh->errstr if $@;
   return $row;
}
---------------8<----------------

E, no arquivo "minhasqueries.sql", você teria a sua query (e todas as
outras que seu programa precisar) separadas por um nome que as
identifique entre colchetes (no caso chamei de "meu_select", mas
recomendo um nome mais significativo), como um arquivo .INI:

---------------8<----------------
# esse select é utilizado pelo blablabla...
# comentários são aceitos, com "#" ou "//"

[meu_select]
SELECT DATE_FORMAT( CURDATE(), '%d/%m/%Y' ) AS "data_atual"
    , UPPER( LEFT( DAYNAME( CURDATE() ), 3 ) ) AS "data_atual_nome"
    , FE.id AS "id"
(...)
---------------8<----------------

Enfim, é isso :-)

[]s

-b

2008/11/6 Gustavo Leite de Mendonça Chaves <gustavo em gnustavo.com>:
> On Tue, Nov 4, 2008 at 2:15 PM, Luis Motta Campos
> <luismottacampos em yahoo.co.uk> wrote:
>>
>> Luis Motta Campos wrote:
>>>
>>> use constant LONG_DUMP_STUPID_QUERY = <<SQL ;
>>
>> Olha que coisa tosca: eu tenho de apontar meus próprios erros de sintaxe,
>> por que ninguém aqui se dá ao trabalho de ler o que eu escrevo. :(
>
> Pelo contrário, Luiz. Li e achei muito interessantes as suas colocações. Eu
> cheguei a começar um email de resposta mas não tinha nada a acrescentar e
> então desisti.
>
> Seu email é o tipo de contribuição que aumenta o valor da lista.
>
> Mas quanto ao typo... eu até percebi o DUMP, mas não me toquei do =>.
>
> Gustavo.
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>


More information about the SaoPaulo-pm mailing list