Documentation about simple_array type suggests it can return null, an empty array is returned instead

[holtkamp]

https://github.com/doctrine/dbal/blob/4.3.x/docs/en/reference/types.rst#simple_array
https://github.com/doctrine/dbal/blob/4.4.x/docs/en/reference/types.rst#simple_array
https://github.com/doctrine/dbal/blob/5.0.x/docs/en/reference/types.rst#simple_array

all end with:

Values retrieved from the database are always converted to PHP's array type using comma delimited explode() or null if no data is present.

The last sentence "or null if no data is present." seems not the way it is implemented: in case no data is present, an empty array is returned according to:

https://github.com/doctrine/dbal/blob/4.3.x/src/Types/SimpleArrayType.php#L43-L45

To me that seems incorrect. An empty array is a different value than NULL. NULL is no value. Why isn't NULL returned as the documentations states? And if the current implementation is the "agreed upon approach", then the documentation should be changed to indicate an array is always returned?

[greg0ire]

It would be interesting to take a look at the git history.

[derrabus]

It would be interesting to take a look at the git history.

I did and it seems it has always been this way for over a decade. And tbh, I don't think this issue is worth fixing. I'd rather remove that broken type entirely.

[holtkamp]

@derrabus

I'd rather remove that broken type entirely.

Do you mean that the documentation should be updated and a "NULL" value in the database would result in an empty array in PHP?

Note that in the documentation https://github.com/doctrine/dbal/blob/5.0.x/docs/en/reference/types.rst the phrase "or null if no data is present." occurs 22 times, so it is used a lot. Not using it for an array would mean an inconsistency...

Would it not be better to prevent inconsistencies and start returning NULL in the next major version as a backward incompatible change?

[derrabus]

Would it not be better to prevent inconsistencies and start returning NULL in the next major version as a backward incompatible change?

No. That's a super subtle change that will break old apps for no reason. If we removed the type, any app that still uses it could simply fork it before upgrading to the next major. I did this in various projects with the "array" type, for example.