Add ArrayType as a generic wrapper for a "list of custom types"

[mpdude]

Q	A
Type	feature
Fixed issues

Summary

The list of parameters conversion is currently limited to a few types expressed by the ArrayParameterType enum.

In doctrine/orm#11897, it might be necessary to express "list of parameters of a given custom type".

As suggested in doctrine/orm#11897 (comment), this PR is an initial exploration of using a new ArrayType to be wrapped around any other underlying type.

[mpdude]

BC break?

[morozov]

My idea was that ArrayType is a Type. It with throw a "not implemented" exception for the SQL declaration (because we can't use it as a column type) but should be able to implement the rest of the methods.

[mpdude]

What would it do to convert a PHP value (an array, probably?) to a database value?

[morozov]

It will delegate the conversion of each element of the array to its element type. We can start simple and accept only Type in the constructor to prove the idea:

public function __construct(private readonly Type $elementType)

[mpdude]

When would it be necessary to use the ArrayType in this way?

[morozov]

When building the query here. If this code builds the parameter types as [new ArrayType('rot13'), 'rot13'], the DBAL should be able to apply rot13 to the array elements similar to how it does with a single value.

[morozov]

After taking a closer look at this, I don't think ArrayType() parameterized with the element type is the right approach. Spoiler alert: even binding a parameter as array in the QueryBuilder::setParameter() or Connection::executeQuery() is the right approach.

Currently, we have two major type systems:

1. Type – represents the type of the entity field and maps to the type of the database column. It can be used in schema definition and in SQL queries.
2. ParameterType – represents the binding type of a variable to an SQL query. It can be used in all sorts of SQL (SELECT, INSERT, UPDATE, etc.)

Also, we have ArrayParameterType, which is sort of a snowflake. All APIs that accept the above two type systems also accept ArrayParameterType, but it only makes sense if used with the IN SQL clause. Therefore, it shouldn't be accepted by all the APIs that accept Type|ParameterType, it should be only accepted by some sort of query builder that accepts an array of values and the element type and returns SQL, parameters and parameter types (a component that can be represented by the Query class.

Any attempt to define the expansion of an array of values to the IN clause by using the existing API will be forcing a square peg into a round hole.