Deprecate driver name aliases

[morozov]

The aliases were initially implemented in #729 as part of the support for connection URLs but there wasn't any public discussion about their design and purpose.

The existing set of aliases is quite illogical and raises questions:

1. The mysql alias prefers the pdo_mysql driver over mysqli. Why?
2. The "MS SQL" and "SQL Server" terms are quite interchangeable but using sqlsrv in the schema will make the sqlsrv driver used while mssql is mapped to pdo_sqlsrv. Why?
3. The mysql2 alias was introduced for

   dbal/src/DriverManager.php

   Line 101 in 2ab7855

   'mysql2' => 'pdo_mysql', // Amazon RDS, for some weird reason

   Why should the DBAL support the schema used by AWS RDS?
4. If the aliases are needed for compatibility with the driver naming of other database-related APIs, how do we validate and maintain the compatibility, and which APIs should the DBAL be compatible with?

Judging by the documentation, the only purpose of using an alias is to avoid using dashes or underscores in connection URLs. Even if that's the case, why do we need more than one alias per driver name? Being able to do one thing in four different ways (pgsql, postgres, postgresql, pdo-pgsql) has rarely been a good idea.

Given that the requirement for using dashes has been documented since the very beginning, I don't believe that this is a problem that requires support for aliases.

[derrabus]

Being able to do one thing in four different ways (pgsql, postgres, postgresql, pdo-pgsql) has rarely been a good idea.

Even worse: pgsql:// might suggest that we're connecting through ext-pgsql while we're actually using PDO. And if we ever were to develop a driver for ext-pgsql (btw: do we want one?), we'd either need to use a non-intuitive URL schema for that or reassign pgsql:// which would be a breaking change.

So 👍🏻 from my side!

[morozov]

btw: do we want one?

I believe at some point the DBAL supported a non-PDO version of the SQLite or PostgreSQL driver. Not sure what happened but unless it brings in some maintenance issues, I don't see a problem adding it. In my experience, the non-PDO drivers provide a nicer API and allow the usage of more features (says a maintainer of the DBAL).

[stof]

the purpose of those aliases was to support credential URLs provided by common PaaS or IaaS platforms, to make it easier to use doctrine/dbal on them (without having to build a scheme-remapping system in the reading of env variables. Those hosting providers are not aware of doctrine/dbal when exposing those URLs (those hosting providers are often not even specific to PHP)

[derrabus]

The problem is that for each database engine (with the exception of Postgres currently) we have two possible drivers that can connect to that database. And it could be more if the application used a custom driver. The decision which of those drivers to use should be made deliberately by the application, especially if the application accesses the native connection in some situations. Right now, the driver being used is the result of a chain of coincidences.

Even worse: Some of the aliases are identical to the name of an existing PHP extension (like sqlite3, pgsql) while in fact they point to the corresponding PDO drivers. In case of sqlite3, we have just added a driver for that extension and removing the alias, which would effectively remap the sqlite3:// scheme from ext-PDO_sqlite to ext-sqlite3 would mean a breaking change.

I understand the problem, but I would still support the deprecation of those hardcoded aliases. If guessing DBAL connection settings from generic database DSNs is a common problem, maybe we can think about moving the DSN parsing to a dedicated class and provide a way to map schemes to drivers. Alternatively, framework integration layers like DoctrineBundle could take over this task.

[stof]

If we specify the driver option explicitly alongside the url, will those schemes still work (favoring the explicit driver above the one that cannot be guessed from the scheme due to not matching) ? Or would the scheme win, giving no chance to configure the driver separately ?
Having to specify the driver option separately would be fine to me (I don't have a use case for dynamically switching driver when the hosting provider updates the credentials in the env variable, as such case will not magically change the platform)