Posso configurar o typecasting do MySQL para considerar 0 != 'foo'?

O problema, porém, é que você está fornecendo um valor numérico, sem aspas, então o MySQL tenta converter o outro lado da comparação como um DOUBLE, para compará-lo com o argumento numérico que você forneceu ... o que deixa você com um 0 isso é equivalente a 0.

mysql> select 'foo' = 0;
+-----------+
| 'foo' = 0 |
+-----------+
|         1 |
+-----------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+-----------------------------------------+
| Level   | Code | Message                                 |
+---------+------+-----------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'foo' |
+---------+------+-----------------------------------------+
1 row in set (0.00 sec)

Se você fornecer o 0 em um contexto de string, isso será avaliado como falso.

mysql> select 'foo' = '0';
+-------------+
| 'foo' = '0' |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)

Portanto, uma opção que você poderia usar para evitar esse comportamento seria converter seu valor de entrada como um CHAR... o que, na maioria das vezes, já é ... mas, se não, será avaliado conforme o esperado.

mysql> select 'foo' = cast(0 as char);
+-------------------------+
| 'foo' = cast(0 as char) |
+-------------------------+
|                       0 |
+-------------------------+
1 row in set (0.00 sec)

update , para responder mais completamente à pergunta:

Posso configurar o MySQL para não fazer esse tipo de typecasting?

Não, não parece haver nenhuma maneira de evitar isso por meio de configuração - apenas por meio de um elenco explícito de sua string de aparência numérica potencial - para uma string, que você disse que não pode ser realizada desde que você está usando um ORM. O local mais provável, se existisse algo assim, seria SQL Server Mode , e nenhuma dessas opções modifica esse comportamento quando se trata de comparações.

Há um pouco de discussão sobre conversões implícitas como esta no Bug #63112 :

SELECIONE laranja > banana;

Isso é verdadeiro ou falso? Bem ... na maioria das vezes uma banana é mais longa que uma laranja. Portanto, se o comprimento for o critério, a afirmação acima é falsa. Mas, na maioria das vezes, uma laranja é mais pesada que uma banana, portanto, se o peso for o critério, a afirmação acima é verdadeira.

Ao comparar diferentes tipos (laranja versus banana, string versus inteiro), alguns 'critérios' ou 'regra' deverão ser usados. Quando o MySQL compara diferentes tipos de dados, eles são [ambos] convertidos para DOUBLE internamente antes da comparação. O inteiro "1" converte para o duplo "1" - a string 'a' ou 'UUID()' converte para o duplo "0". [...]

Observe que o escopo deste relatório de bug não é estritamente limitado a conversão implícita em contexto externo, e a menção UUID()aqui é um pouco distrativa, pois UUID()pode retornar strings começando com dígitos e converter para outros números ... mas acho que serve para confirmar que não existe alternativa, pois nada é apresentado além de "não use tipos diferentes para comparação se quiser evitar um elenco", que já sabemos. Isto continua:

Para evitar a conversão para DOUBLEgarantir internamente que os valores comparados sejam do mesmo tipo de dados. No seu caso, as idcolunas são strings e o valor com o qual você compara também deve ser strings (não 1, mas '1' - não 2, mas '2' etc.) ou use cast()/ convert()em sua declaração [...]

Em relação à sua sugestão de que, se a conversão implícita for feita, o número deve se tornar uma string em vez da string se tornar um número ... Posso ver seu ponto, até certo ponto, para comparações de igualdade estrita ... mas há muitos outros operadores além =e usando essa lógica, surge toda uma nova série de problemas...

mysql> SELECT CAST(100 AS CHAR) < '2';
+-------------------------+
| CAST(100 AS CHAR) < '2' |
+-------------------------+
|                       1 |
+-------------------------+
1 row in set (0.00 sec)

Correto! A string '100' é "menor que" a string '2' em sentido alfabético... da mesma forma que a string 'AXX' é "menor que" a string 'B'. Portanto, essa alternativa certamente tem suas desvantagens.

Existe, no entanto, uma terceira alternativa, que parece ser a lógica mais precisa (embora eu aceite uma objeção construtiva): Se uma string que começa com um caractere não-dígito é convertida para a DOUBLE(ou qualquer outro tipo numérico, nesse caso ), parece que o resultado mais correto dessa conversão seria NULL .

Infelizmente, esta não é a abordagem do MySQL. Parece que isso pode ser corrigido na fonte, possivelmente sql/field.cconde o '0' retornado por my_strntod () parece ser simplesmente retornado ao chamador após lançar o aviso se ocorreu um erro, mas tentando tal hack tão profundo na fonte está além da minha especialidade.

Primeiro, se sua consulta final estava sendo gerada dessa forma, parece implicar em pegar a entrada direta do usuário e colá-la em um modelo de consulta, o que em si é o problema da injeção de SQL. Além disso, mesmo se você estivesse fazendo isso, o modelo de consulta precisaria estar entre aspas para que as solicitações legítimas de entradas charish fossem sintaticamente válidas.

Qualquer que seja a linguagem que seu aplicativo esteja usando, ruby ​​ou não, procure como eles fazem consultas parametrizadas e instruções preparadas. A API cuidará de todo o escape adequado para você.