count() method is returning string not integer about db

[dynasource]

whether there is an abstraction layer between it or not, one expects a count function to return a number, not a string. This is the most intuitive result.

[rob006]

I would say that we should do it a long time ago. W can safely convert count() result to int, so there is no technical problem here.

[rob006]

The only con is that we'll have int|string as a type hint :(

Numerical string will be returned only in edge cases (when you need integer bigger than your environment can handle). We could:

1. Laravel style - f*ck edge cases and always cast to int.
2. Remove string from typehint - in 99.9999% cases you will get int anyway, so string in typehint may give more harm than good.

@ptz-nerf This is not a code sample. How do you want to use === on comparing result with integer that cannot be represented as integer?

[schmunk42]

I'd also expect an integer here.

From https://stackoverflow.com/questions/670662/whats-the-maximum-size-for-an-int-in-php even on 32bit systems this would be limited to ~2 billion, which is quite large and on 64bit to ~9 quintillion.

[cebe]

This is normal because PDO does always return strings regardless what value it was on DB side. Because PHP is not stricly typed this should not be a problem.

[nenad-zivkovic]

If you are doing strict comparisons of result and some integer value it is. But of course, it is a question do you really need to do strict comparison at all... I guess it is not a "real" problem. Thanks for info.

[cebe]

You should only do strict comparison if you are really sure or really need to. This is not such a case.

[ptz-nerf]

if you are really sure

When can count() return not integer number? string|int return type is missleading: people expect to see the number, suspecting that string will be return in a rare strange situation. Everything is quite the opposite, int (0) will be return only if emulateExecution is true...

[rob006]

#14704

[samdark]

Hmm... yes. We can't do it :(

[samdark]

32bit ints?

[rob006]

With approach from #14704 it will be represented as numerical string.

[samdark]

But that's quite inconsistent. It's better to cast to string than to have two types. Developers will use === and will be quite surprised when the project DB would exceed 32bit int.

[rob006]

Developers will use === and will be quite surprised when the project DB would exceed 32bit int.

Can you give a code sample, when this will happen? You will get string only if result cannot be converted to integer, so how do you want to use === in this case?

BTW: Developers are already surprised that count() returns string. And such inconsistency already exists in AR.

[ptz-nerf]

#14704
Indeed, string is better.

[samdark]

Actually what @rob006 proposes makes sense in practice. While under a 100 it may make sense to strictly compare counts, more than several thousands should always be done with > or < and for these operators it doesn't really make any difference if operands are strings or ints.

The only con is that we'll have int|string as a type hint :(

[samdark]

Let's cast to int as @rob006 originally proposed. @yiisoft/core-developers objections?

[ptz-nerf]

Given that the result can be of different types on any numbers (yiisoft/yii2#14704 (comment)), it is better to have int (with @rob006 check) in most situations. On x64 it is insignificant. string really surprised me at the first moment.

[SilverFire]

No objections

[terabytesoftw]

done.