Feature: optionally use mysql (but keep postgres as the default)

[BurningDog]

Q	A
Branch?	main
Tickets	#1965 #797 (comment) #594
License	MIT
Doc PR	TODO

Background: I would like to have the option to have API Platform use mysql instead of postgres. Someone made an entirely new repo just to implement this feature, although it's unmaintained.

This PR adds mysql, but keeps postgres as default. It does this by:

• extracting the postgres setup to a separate docker-compose.postgres.yml file
• adding mysql setup to a docker-compose.mysql.yml file
• adding a top level .env file for docker-compose to use, which selects postgres by default (but can also be edited to use mysql instead)
• adding a variable to the Dockerfile to select with postgres or mysql
• editing the single migration file to switch between sql for postgres or mysql

To use mysql:

• edit the .env file, comment out the postgres lines, and uncomment the following lines:

# mysql
DATABASE_ENGINE=mysql
## Dev environment
COMPOSE_FILE=docker-compose.yml:docker-compose.mysql.yml:docker-compose.override.yml

• edit the Dockerfile and change ARG DATABASE_ENGINE=postgresql to ARG DATABASE_ENGINE=mysql
• run docker-compose build
• run docker-compose up

Additional notes/concerns

• Some changes are needed to helm/api-platform/values.yaml but I'm not enough of a Helm/Kubernetes wizard to see what needs to happen. I compared https://github.com/bitnami/charts/blob/master/bitnami/postgresql/values.yaml to https://github.com/bitnami/charts/blob/master/bitnami/mysql/values.yaml and tried to intuit what values would be needed, but this should be rather done by someone invested in running mysql on kubernetes.
• I haven't yet written a documentation PR, but will do once I have some feedback on this one.
• The biggest downside with this PR is that it does introduce an .env file for docker-compose to use, and adds some more yaml files - which makes the docker setup less intuitive. However, the big benefit is that it allows for using mysql, while maintaining the current default.
• I haven't written tests for mysql, as this would double the runtime of CI builds.
• The PR template says to update the CHANGELOG.md file, but I don't see one.
• This entire PRs commits need to be squashed and merge if it gets approved, as I needed to do a number of exploratory commits and test that they worked.
• re: Switching to MySQL #594 - it's possible that instead of this PR, using mysql is rather documented in the documentation repo. The benefit is less docker-compose complexity (and not worrying about tests not running on mysql); the downside is that it's some manual setup every time a new person wants to run mysql. I leave it to the maintainers to decide whether this PR should be solely on the docs repo.
• re: Simplify deploy with docker-compose #1965 - this PR already proposed using the .env file, but looks abandoned. There's also a question there about moving more environment variables from the docker-compose.yml into the .env file, but I had some issues with that, so would rather first land this PR before digging in that more.

[BurningDog]

If I add this to the top of the file, then it's inaccessible at this point. I have no idea why, but it was a pretty frustrating 30 mins of trying to wrangle around it.

[BurningDog]

This section is so that the api-platform mysql user can create a test database.

[dunglas]

Thanks for the contribution, however we don't plan to merge such feature. It increases the complexity and the maintenance burden. Also, Symfony Flex recipes only support Postgres by default too.
Would you mind opening a documentation PR instead?

[BurningDog]

@dunglas yes, for sure - after working with this for a few days, I agree on the increased complexity - it's better to commit to either one database or the other.

I'll open a documentation PR.