URL-style DSNs (e.g. mysql://foo@bar:localhost/db
) are now assumed to be percent-encoded
in order to allow certain special characters in usernames, paswords and database names. If
you are using a URL-style DSN and have a username, password or database name containing a
percentage sign, you need to update your DSN. If your password is, say, foo%foo
, it
should be encoded as foo%25foo
.
When adding indexes to Doctrine\DBAL\Schema\Table
via addIndex()
or addUniqueIndex()
,
duplicate indexes are not silently ignored/dropped anymore (based on semantics, not naming!).
Duplicate indexes are considered indexes that pass isFullfilledBy()
or overrules()
in Doctrine\DBAL\Schema\Index
.
This is required to make the index renaming feature introduced in 2.5.0 work properly and avoid
issues in the ORM schema tool / DBAL schema manager which pretends users from updating
their schemas and migrate to DBAL 2.5.*.
Additionally it offers more flexibility in declaring indexes for the user and potentially fixes
related issues in the ORM.
With this change, the responsibility to decide which index is a "duplicate" is completely deferred
to the user.
Please also note that adding foreign key constraints to a table via addForeignKeyConstraint()
,
addUnnamedForeignKeyConstraint()
or addNamedForeignKeyConstraint()
now first checks if an
appropriate index is already present and avoids adding an additional auto-generated one eventually.
When mapping time
type field to PHP's DateTime
instance all unused date fields are
reset to UNIX epoch (i.e. 1970-01-01). This might break any logic which relies on comparing
DateTime
instances with date fields set to the current date.
Use !
format prefix (see http://php.net/manual/en/datetime.createfromformat.php) for parsing
time strings to prevent having different date fields when comparing user input and DateTime
instances as mapped by Doctrine.
The methods addIndex()
and addUniqueIndex()
in Doctrine\DBAL\Schema\Table
have an additional, optional parameter. If you override these methods, you should
add this new parameter to the declaration of your overridden methods.
The visibility of the property $_platform
in Doctrine\DBAL\Connection
was changed from protected to private. If you have subclassed Doctrine\DBAL\Connection
in your application and accessed $_platform
directly, you have to change the code
portions to use getDatabasePlatform()
instead to retrieve the underlying database
platform.
The reason for this change is the new automatic platform version detection feature,
which lazily evaluates the appropriate platform class to use for the underlying database
server version at runtime.
Please also note, that calling getDatabasePlatform()
now needs to establish a connection
in order to evaluate the appropriate platform class if Doctrine\DBAL\Connection
is not
already connected. Under the following circumstances, it is not possible anymore to retrieve
the platform instance from the connection object without having to do a real connect:
Doctrine\DBAL\Connection
was instantiated without theplatform
connection parameter.Doctrine\DBAL\Connection
was instantiated without theserverVersion
connection parameter.- The underlying driver is "version aware" and can provide different platform instances for different versions.
- The underlying driver connection is "version aware" and can provide the database server version without having to query for it.
If one of the above conditions is NOT met, there is no need for Doctrine\DBAL\Connection
to do a connect when calling getDatabasePlatform()
.
Before 2.5 the DateTime type always required a specific format, defined in
$platform->getDateTimeFormatString()
, which could cause quite some troubles
on platforms that had various microtime precision formats. Starting with 2.5
whenever the parsing of a date fails with the predefined platform format,
the date_create()
function will be used to parse the date.
This could cause some troubles when your date format is weird and not parsed
correctly by date_create
, however since databases are rather strict on dates
there should be no problem.
The pdo_ibm
driver is buggy and does not work well with Doctrine. Therefore it will no
longer be supported and has been removed from the Doctrine\DBAL\DriverManager
drivers
map. It is highly encouraged to to use ibm_db2
driver instead if you want to connect
to an IBM DB2 database as it is much more stable and secure.
If for some reason you have to utilize the pdo_ibm
driver you can still use the driverClass
connection parameter to explicitly specify the Doctrine\DBAL\Driver\PDOIbm\Driver
class.
However be aware that you are doing this at your own risk and it will not be guaranteed that
Doctrine will work as expected.
If you have custom classes that implement the constraint interface, you have to implement
an additional method getQuotedColumns
now. This method is used to build proper constraint
SQL for columns that need to be quoted, like keywords reserved by the specific platform used.
The method has to return the same values as getColumns
only that those column names that
need quotation have to be returned quoted for the given platform.
Before 2.3 the Oracle Session Init did not care about the numeric character of the Session. This could lead to problems on non english locale systems that required a comma as a floating point seperator in Oracle. Since 2.3, using the Oracle Session Init on connection start the client session will be altered to set the numeric character to ".,":
ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '.,'
See DBAL-345 for more details.
The query related methods including but not limited to executeQuery, exec, query, and executeUpdate now wrap the driver exceptions such as PDOException with DBALException to add more debugging information such as the executed SQL statement, and any bound parameters.
If you want to retrieve the driver specific exception, you can retrieve it by calling the
getPrevious()
method on DBALException.
Before:
catch(\PDOException $ex) {
// ...
}
After:
catch(\Doctrine\DBAL\DBALException $ex) {
$pdoException = $ex->getPrevious();
// ...
}
This method only worked on MySQL and it is considered unsafe on MySQL to use SET NAMES UTF-8 instead of setting the charset directly on connection already. Replace this behavior with the connection charset option:
Before:
$conn = DriverManager::getConnection(array(..));
$conn->setCharset('UTF8');
After:
$conn = DriverManager::getConnection(array('charset' => 'UTF8', ..));
Doctrine\DBAL\Schema\Table#renameColumn() was removed, because it drops and recreates the column instead. There is no fix available, because a schema diff cannot reliably detect if a column was renamed or one column was created and another one dropped.
You should use explicit SQL ALTER TABLE statements to change columns names.
The Filter Schema assets expression is not wrapped in () anymore for the regexp automatically.
Before:
$config->setFilterSchemaAssetsExpression('foo');
After:
$config->setFilterSchemaAssetsExpression('(foo)');
If you are creating a new MySQL Table through the Doctrine API, charset/collate are now set to 'utf8'/'utf8_unicode_ci' by default. Previously the MySQL server defaults were used.
Both methods now accept an optional last parameter $types with binding types of the values passed. This can potentially break child classes that have overwritten one of these methods.
Doctrine\DBAL\Connection#executeQuery() got a new last parameter "QueryCacheProfile $qcp"
The Driver statement was split into a ResultStatement and the normal statement extending from it. This separates the configuration and the retrieval API from a statement.
The MsSqlPlatform was renamed to SQLServerPlatform, the MsSqlSchemaManager was renamed to SQLServerSchemaManager.
DBAL 2.1 and before were actually only compatible to SQL Server 2008, not earlier versions. Still other parts of the platform did use old features instead of newly introduced datatypes in SQL Server 2005. Starting with DBAL 2.2 you can pick the Doctrine abstraction exactly matching your SQL Server version.
The PDO SqlSrv driver now uses the new SQLServer2008Platform
as default platform.
This platform uses new features of SQL Server as of version 2008. This also includes a switch
in the used fields for "text" and "blob" field types to:
"text" => "VARCHAR(MAX)"
"blob" => "VARBINARY(MAX)"
Additionally SQLServerPlatform
in DBAL 2.1 and before used "DATE", "TIME" and "DATETIME2" for dates.
This types are only available since version 2008 and the introduction of an explicit
SQLServer 2008 platform makes this dependency explicit.
An SQLServer2005Platform
was also introduced to differentiate the features between
versions 2003, earlier and 2005.
With this change the SQLServerPlatform
now throws an exception for using limit queries
with an offset, since SQLServer 2003 and lower do not support this feature.
To use the old SQL Server Platform, because you are using SQL Server 2003 and below use the following configuration code:
use Doctrine\DBAL\DriverManager;
use Doctrine\DBAL\Platforms\SQLServerPlatform;
use Doctrine\DBAL\Platforms\SQLServer2005Platform;
// You are using SQL Server 2003 or earlier
$conn = DriverManager::getConnection(array(
'driver' => 'pdo_sqlsrv',
'platform' => new SQLServerPlatform()
// .. additional parameters
));
// You are using SQL Server 2005
$conn = DriverManager::getConnection(array(
'driver' => 'pdo_sqlsrv',
'platform' => new SQLServer2005Platform()
// .. additional parameters
));
// You are using SQL Server 2008
$conn = DriverManager::getConnection(array(
'driver' => 'pdo_sqlsrv',
// 2008 is default platform
// .. additional parameters
));