Ha. Even more sad of CF if one looks at the metadata:

To me this is a bug in CF though (for reasons previously stated)

But… OK… CFML is shit with types in a query.

I give up.

There’s the compat situation still, but I’ve stopped caring, TBH. I’d not sink any time into this if I was yuo. And I thank you for feeding back, nevertheless.

If you closed this as “won’t fix”, I’d be fine with this.

ACF has some superficial controls for query, that Lucee does not have, but still ACF like Lucee does see the types with query NOT as binding, just some rules loosely attached, take this example:

this works perfectly fine with Lucee and ACF, when i set a not number on line 2, ACF like lucee reset type for the column.

The only difference between ACF and Lucee is, that acf has some superficial controls and because of that the following code lines are not acting the same way in every situation in ACF

When we implemented this, we decided not to handle the type differently based in the syntax, it should not matter if you do line 1 or 2, they should be identical.

We can add this superficial controls, but in my opinion they are pointless, when they are not consistent. what do you think?

changing that behaviour would break backward compatibility

This is pretty woolly thinking: intrinsically bug fixes always break backwards compatibility. This is the nature of changing from [buggy behaviour] to [not buggy behaviour].

If anyone is leveraging a situation wherein they say “the data for this needs to be an int”, but still expect non-int values to work, well… TBH that’s so banally far-fetched as to be not really something one needs to consider.

Whereas there is quite likely reasonable real-world cases where people will actually appreciate finding out “why did this break? Oh shit, it’s cos it’s wrong”.

These are not two equally valid positions. The former position is invalid.

This is not a situation where CFML has been loose with types; it’s a situation where CFML is stringent with types (these situations are not new or rare, either): running the code on CF demonstrates this.

Accepting “NOT_AN_INT” as a value for something that is specifically set to require an int is objectively wrong. It’s a bug.

There does not need to be an Application.cfc setting for the fix for this bug any more than there needs to be one for any other bug.

i have rejected the PR, IF we do that this need to be based on a setting that by default keep the original behaviour, the easiest way would be a application.cfc setting

https://github.com/lucee/Lucee/pull/2130

i write the following without analyse the ticket in detail YET. But the following is essential when it comes to types with CFML (ACF and Lucee).

In CFML the type definitions for queries are loose. means if a type does not match CFML simply gives up. That is because this type handling already existed before types got indroduced to CFML, so for backward compatibility query types act differently than the rest of CFML. so in that context types are mor a guidance and not a rule.

changing that behaviour would break backward compatibility, i already did in the past and got a lot of shit because of it.