This is surprisingly not intuitive, as you cannot simply pass an array of integers to a prepared statement. Instead, you need to add special binding types to inform Doctrine that this is indeed an array of integers.

It’s very well explained in the documentation under the Parameters Conversion section:
https://www.doctrine-project.org/projects/doctrine-dbal/en/current/reference/data-retrieval-and-manipulation.html#list-of-parameters-conversion
But it is rather hard to find and it took me a while.

The trick is to add the array binding types to the the types parameters to the query method. In the case of integers, it is \Doctrine\DBAL\ArrayParameterType::INTEGER.
Now Doctrine knows how to handle the types in the array while binding the values.

Example:

$sql = 'SELECT * FROM items WHERE id IN (?)'; 
$numbersAsStrings = "1,2,3";
$numbers = array_map('intval', explode(',', $numbersAsStrings));
$users = $con->fetchAllAssociative(
  $sql, 
  [$numbers], 
  [ArrayParameterType::INTEGER]
);

If you omit the types, Doctrine will simply try to bind the array as string, which will fail and you get this error:
Array to string conversion

If you try to pass it as a comma-separated string yourself and omit the types like $numbers = implode(',',array_map('intval', explode(',', $numbersAsStrings))); You will get an error because Doctrine expects an array of values for the IN clause and not a string.
Error:
count(): Argument #1 ($value) must be of type Countable|array, string given

I hope this helps someone finding out how to make WHERE IN SQL queries with Doctrine more quickly than me next time.

my_db.mysql      | 2024-08-16T09:40:21.463770Z 2 [ERROR] [MY-010520] [Server] Invalid (old?) table or database name 'mysql.sock'
my_db.mysql      | 2024-08-16T09:40:21.468287Z 2 [ERROR] [MY-010784] [Server] Failed to open dir /var/lib/mysql/mysql.sock

Apparently, MySQL 8 treats every file or directory in the data directory as a database table, whereas in the previous version, MySQL 5, only directories were recognized as database tables.

As the the changelog of MySql 8 states:

Because the data dictionary provides information about database objects, the server no longer checks directory names in the data directory to find databases. Consequently, the --ignore-db-dir option and ignore_db_dirs system variable are extraneous and have been removed. Update system configurations and application programs accordingly.

As a result, all files in the data directory volume, in addition to the directories, are mistakenly recognized as database tables–for example, the mysql.sock file, which is created by Docker.

The solution is to separate the actual database tables from the metadata files. We need to move all table files to a dedicated data directory and configure MySQL to use this new location.
Then let’s move all database data to dedicated data dir:

mkdir data
mv * ./data/

And specify the dataDir in my.cnf:
datadir=/var/lib/mysql/data

Now MySql will only look for database table files in this directory and Docker still can write to the main MySql directory.
And, most importantly, the database will start up again.

There are several ways to import the data in your docker-compose setup.

1. Using a volume for import data
2. Using mysql client from commandline with docker-compose exec
3. Using phpmyadmin in docker-compose setup
4. Using a mysql GUI client on the host and connect to the DB in the Docker container

So let’s see how we can do this:

1. Using a volume for import data

This applies to both official Mysql and MariaDB official images.
These have builtin import mechanism to import data.
To quote from the docs:

Furthermore, it will execute files with extensions .sh, .sql and .sql.gz that are found in /docker-entrypoint-initdb.d. Files will be executed in alphabetical order. You can easily populate your mysql services by mounting a SQL dump into that directory

So all dumps that are found in the /docker-entrypoint-initdb.d directory of the image will be imported unless the database already contains data.

So let’s add this volume to our docker-compose.yaml

volumes: - ./database_dump.sql:/docker-entrypoint-initdb.d/datadump.sql

On next docker-compose up the data will be imported in your empty database.
You will see something like this in your docker-compose logs:

2023-02-06 15:40:16+00:00 [Note] [Entrypoint]: /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/database_dump.sql

Note: if there is already data in the database you need to clear the data first by f.e. clearing the volume, otherwise the import will not start:
You can clear all volumes of your docker-compose setup with (caution: this will clear all volumes, not just the database volume):

docker-compose down -v

2. Using mysql client from commandline with docker-compose exec

With this one liner you can import a SQL dump from a docker image that has a MySql/MariaDB client installed and are linked to the DB container:

docker-compose exec my-app bash -c "mysql -u root -h mysql --password=root database < database_dump.sql"

This will execute the application image and import the data with the mysql client which connects to the host mysql which is the linked mysql container.

3. Use phpmyadmin in docker-compose setup

If the above is too consolish then you also can just add a phpmyaadmin container in your docker-compose setup and administer the database with a GUI from the browser.

  myproject_phpmyadmin:
	image: phpmyadmin/phpmyadmin:latest
	ports:
	  - 8080:80
	environment:
	  PMA_HOST: myproject_mysql

Then you can just open http://localhost:8080 in the browser and log into to Phpmyadmin.
To import data go to the import tab and upload the dump file.

4. Using a mysql GUI client on the host and connect to the DB in the Docker container

For this approach you just need to open a port in the database container to the outside and use this port with localhost in the settings of your database client.

  myproject_mysql:
    image: mysql:5.7
    hostname: mysql.${DOMAIN}
    container_name: ${CONTAINER_NAME}.mysql
      volumes:
	- ${PWD}/data/mysql/:/var/lib/mysql
	- ./container/mysql/my.cnf:/etc/mysql/conf.d/z_my.cnf
    ports: # open the mysql port to the host
      - "3306:3306"
    environment:
  ...

See this screenshot from IntellIj’s PHPStorm Database tool:

From my experience these clients are very good to check data but not so good for import, at least I had rather poor experience in the PHPStorm DB Tool.
So going consolish on imports is recommended :)

An exception occurred while executing 'INSERT INTO user (id, email, roles, password, is_verified) VALUES (?, ?, ?, ?, ?)' with params [3, "dev@dev.de", "[]", "your-encrypted-password", 0]:
SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "user"
LINE 1: INSERT INTO user (id, email, roles, password, is_verified) V...

To fix this you have to escape the table name on your entity, fe. User.php:

@ORM\Table(name="`user`")

(note the backticks inside the quotes!)

If you generate the entity with maker bundle: bin/console make:entity directly on Postgres the backticks are added automatically.
But not when you switch the DB type. Then you have to add them manually. :)

Unknown MySQL server host <mysql-service-name>

… and you dont know why because everything seems to be correct.

Then you might have an upgrade problem with mysql because you are reusing an old volume that was created for another mysql version.
This can happen when you use a unspecified tag as mysql:latest (not recommended anyway) and there was a version bump in the official mysql image.
Or you upgraded the mysql container yourself, f.e. from mysql:5.6 to mysql:5.7 and you are reusing the data volume with the mysql files.

When you check the startup logs you might see that mysql container is shutting down after startup because of an error like this:

Can't open the mysql.plugin table. Please run mysql_upgrade to create it.

You can run the upgrade command in the container:

docker exec -it mysql_container_name bash -c "mysql_upgrade -uroot -proot"

Or simply delete the volume and recreate it.
Note: the data will unfortunatly be lost. So better dump the data before deleting the volume and reimport it.
In my case its no problem because im starting a new project anyway.

To delete the volume you can:

docker volume rm <volume id>

Or just delete the data dir:

rm -rf ./data/mysql

Then restart your setup so the mysql container recreates the databases:

docker-compose up

and mysql is working again and the application is able to connect. :)