Programando Python Embutido com Claude Code: Uma pequena armadilha

O Claude Code tem uma compreensão sólida do IRIS, mas problemas inesperados ainda ocorrem.

O primeiro problema é um que já aconteceu várias vezes e provavelmente continuará ocorrendo se não for devidamente abordado.

No IRIS, a colação para dados de string (%String) é definida como SQLUPPER por padrão. Como resultado, quando os dados são recuperados via SQL, eles podem ser retornados em letras maiúsculas (por exemplo, ao ordenar e agregar com GROUP BY).

Se você não estiver ciente desse comportamento (e a maioria das pessoas geralmente não está) e der instruções ao Claude Code que dependam dos valores reais desses dados, poderá não obter os resultados esperados.

Por exemplo, se você instruí-lo a extrair dados onde o valor de uma coluna seja igual a “Support”, ele pode gerar uma condição como = 'Support' na consulta SQL.

No entanto, como o valor real retornado é “SUPPORT”, a condição não corresponde.

Este problema provavelmente pode ser evitado documentando explicitamente esse comportamento nas instruções do Claude Code ou alterando a configuração COLLATE na definição da classe para SQLSTRING.

Outro problema que encontrei recentemente é algo que seria bastante difícil de lidar.

Como muitos de vocês devem saber, o IRIS possui um recurso muito útil chamado campos calculados (calculated fields).

Embora conveniente, esse recurso também é extremamente flexível e, se você não tomar cuidado, pode levar a situações questionáveis do ponto de vista do SQL.
O problema desta vez envolveu o seguinte campo calculado:
 

Property ReportMD As %Integer [ Calculated, SqlComputeCode = {set {*} = $translate($justify({ReportMonth},2)," ",0)_$translate($justify({ReportDay},2)," ",0)}, SqlComputed ];

Este campo calculado formata o mês e o dia no formato MMDD, fixo em quatro dígitos para fins de impressão e outros propósitos.

Por exemplo, 3 de março seria representado como 0303.

O problema aqui é que o tipo está definido como %Integer.

(O motivo para usar %Integer é, como mencionado abaixo, permitir comparações numéricas.)

Se este fosse um campo físico, tentar inserir um valor como 0303 diretamente resultaria em um erro de validação. No entanto, com um campo calculado, o valor pode ser transformado em qualquer formato via código.

O problema surgiu quando pedi ao Claude Code para gerar uma consulta SQL para comparar datas usando este campo calculado.

O código gerado não funcionou corretamente, então solicitei uma revisão.

Nesse ponto, o Claude Code passou um tempo excepcionalmente longo tentando resolver o problema, eventualmente esgotando seus recursos disponíveis e relatando que não poderia continuar.

Investiguei então adicionando código de depuração à saída gerada e descobri que a consulta SQL não estava produzindo os resultados pretendidos.

Após analisar a causa raiz, descobri que a seguinte condição:

where (reportmd >= ? and reportmd <= ?

não estava se comportando como esperado.

Do ponto de vista do SQL, 0401 não é tratado como um valor numérico, então esse comportamento é compreensível.

A solução acabou sendo:

where (+reportmd >= ? and +reportmd <= ?

o que força a avaliação numérica ao prefixar o campo com um sinal de mais.

Este é o tipo de problema que seria extremamente difícil para o Claude Code identificar, por mais que tente.

(Finalmente entendi por que ele esgotou seus recursos.)

A causa raiz reside na ambiguidade inerente à definição original, portanto, ao usar IA generativa para codificação, parece importante antecipar tais problemas com antecedência e projetar de uma forma que os evite.

Em qualquer caso, espero que surjam mais situações inesperadas, mas espero acumular conhecimento e experiência passo a passo.