Doctrine Configuration Reference (DoctrineBundle)
Warning: You are browsing the documentation for Symfony 6.3, which is no longer maintained.
Read the updated version of this page for Symfony 7.1 (the current stable version).
The DoctrineBundle integrates both the DBAL and
ORM Doctrine projects in Symfony applications. All these
options are configured under the doctrine
key in your application
configuration.
1 2 3 4 5
# displays the default config values defined by Symfony
$ php bin/console config:dump-reference doctrine
# displays the actual config values used by your application
$ php bin/console debug:config doctrine
Note
When using XML, you must use the http://symfony.com/schema/dic/doctrine
namespace and the related XSD schema is available at:
https://symfony.com/schema/dic/doctrine/doctrine-1.0.xsd
Doctrine DBAL Configuration
DoctrineBundle supports all parameters that default Doctrine drivers accept, converted to the XML or YAML naming standards that Symfony enforces. See the Doctrine DBAL documentation for more information. The following block shows all possible configuration keys:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
doctrine:
dbal:
dbname: database
host: localhost
port: 1234
user: user
password: secret
driver: pdo_mysql
# if the url option is specified, it will override the above config
url: mysql://db_user:db_password@127.0.0.1:3306/db_name
# the DBAL driverClass option
driver_class: App\DBAL\MyDatabaseDriver
# the DBAL driverOptions option
options:
foo: bar
path: '%kernel.project_dir%/var/data/data.sqlite'
memory: true
unix_socket: /tmp/mysql.sock
# the DBAL wrapperClass option
wrapper_class: App\DBAL\MyConnectionWrapper
charset: utf8mb4
logging: '%kernel.debug%'
platform_service: App\DBAL\MyDatabasePlatformService
server_version: '5.7'
mapping_types:
enum: string
types:
custom: App\DBAL\MyCustomType
Note
The server_version
option was added in Doctrine DBAL 2.5, which
is used by DoctrineBundle 1.3. The value of this option should match
your database server version (use postgres -V
or psql -V
command
to find your PostgreSQL version and mysql -V
to get your MySQL
version).
If you are running a MariaDB database, you must prefix the server_version
value with mariadb-
(e.g. server_version: mariadb-10.4.14
). This will
change in Doctrine DBAL 4.x, where you must define the version as output by
the server (e.g. 10.4.14-MariaDB
).
Always wrap the server version number with quotes to parse it as a string
instead of a float number. Otherwise, the floating-point representation
issues can make your version be considered a different number (e.g. 5.7
will be rounded as 5.6999999999999996447286321199499070644378662109375
).
If you don't define this option and you haven't created your database
yet, you may get PDOException
errors because Doctrine will try to
guess the database server version automatically and none is available.
If you want to configure multiple connections in YAML, put them under the
connections
key and give them a unique name:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
doctrine:
dbal:
default_connection: default
connections:
default:
dbname: Symfony
user: root
password: null
host: localhost
server_version: '5.6'
customer:
dbname: customer
user: root
password: null
host: localhost
server_version: '5.7'
The database_connection
service always refers to the default connection,
which is the first one defined or the one configured via the
default_connection
parameter.
Each connection is also accessible via the doctrine.dbal.[name]_connection
service where [name]
is the name of the connection. In a controller
you can access it using the getConnection()
method and the name of the connection:
1 2 3 4 5 6 7 8 9 10 11 12 13
// src/Controller/SomeController.php
use Doctrine\Persistence\ManagerRegistry;
class SomeController
{
public function someMethod(ManagerRegistry $doctrine): void
{
$connection = $doctrine->getConnection('customer');
$result = $connection->fetchAll('SELECT name FROM customer');
// ...
}
}
Doctrine ORM Configuration
This following configuration example shows all the configuration defaults that the ORM resolves to:
1 2 3 4 5 6 7 8 9 10 11 12
doctrine:
orm:
auto_mapping: true
# the standard distribution overrides this to be true in debug, false otherwise
auto_generate_proxy_classes: false
proxy_namespace: Proxies
proxy_dir: '%kernel.cache_dir%/doctrine/orm/Proxies'
default_entity_manager: default
metadata_cache_driver: array
query_cache_driver: array
result_cache_driver: array
naming_strategy: doctrine.orm.naming_strategy.default
There are lots of other configuration options that you can use to overwrite certain classes, but those are for very advanced use-cases only.
Shortened Configuration Syntax
When you are only using one entity manager, all config options available
can be placed directly under doctrine.orm
config level.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
doctrine:
orm:
# ...
query_cache_driver:
# ...
metadata_cache_driver:
# ...
result_cache_driver:
# ...
connection: ~
class_metadata_factory_name: Doctrine\ORM\Mapping\ClassMetadataFactory
default_repository_class: Doctrine\ORM\EntityRepository
auto_mapping: false
naming_strategy: doctrine.orm.naming_strategy.default
hydrators:
# ...
mappings:
# ...
dql:
# ...
filters:
# ...
This shortened version is commonly used in other documentation sections. Keep in mind that you can't use both syntaxes at the same time.
Caching Drivers
Use any of the existing Symfony Cache pools or define new pools to cache each of Doctrine ORM elements (queries, results, etc.):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
# config/packages/prod/doctrine.yaml
framework:
cache:
pools:
doctrine.result_cache_pool:
adapter: cache.app
doctrine.system_cache_pool:
adapter: cache.system
doctrine:
orm:
# ...
metadata_cache_driver:
type: pool
pool: doctrine.system_cache_pool
query_cache_driver:
type: pool
pool: doctrine.system_cache_pool
result_cache_driver:
type: pool
pool: doctrine.result_cache_pool
# in addition to Symfony Cache pools, you can also use the
# 'type: service' option to use any service as the cache
query_cache_driver:
type: service
id: App\ORM\MyCacheService
Mapping Configuration
Explicit definition of all the mapped entities is the only necessary configuration for the ORM and there are several configuration options that you can control. The following configuration options exist for a mapping:
type
One of annotation
(for PHP annotations; it's the default value),
attribute
(for PHP attributes), xml
, yml
, php
or
staticphp
. This specifies which type of metadata type your mapping uses.
See Doctrine Metadata Drivers for more information about this option.
dir
Absolute path to the mapping or entity files (depending on the driver).
prefix
A common namespace prefix that all entities of this mapping share. This prefix should never conflict with prefixes of other defined mappings otherwise some of your entities cannot be found by Doctrine.
alias
Doctrine offers a way to alias entity namespaces to simpler, shorter names to be used in DQL queries or for Repository access.
is_bundle
This option is false
by default and it's considered a legacy option. It was
only useful in previous Symfony versions, when it was recommended to use bundles
to organize the application code.
Custom Mapping Entities in a Bundle
Doctrine's auto_mapping
feature loads attribute configuration from
the Entity/
directory of each bundle and looks for other formats (e.g.
YAML, XML) in the Resources/config/doctrine
directory.
If you store metadata somewhere else in your bundle, you can define your own mappings, where you tell Doctrine exactly where to look, along with some other configurations.
If you're using the auto_mapping
configuration, you just need to overwrite
the configurations you want. In this case it's important that the key of
the mapping configurations corresponds to the name of the bundle.
For example, suppose you decide to store your XML
configuration for
AppBundle
entities in the @AppBundle/SomeResources/config/doctrine
directory instead:
1 2 3 4 5 6 7 8 9 10
doctrine:
# ...
orm:
# ...
auto_mapping: true
mappings:
# ...
AppBundle:
type: xml
dir: SomeResources/config/doctrine
Mapping Entities Outside of a Bundle
For example, the following looks for entity classes in the Entity
namespace in the src/Entity
directory and gives them an App
alias
(so you can say things like App:Post
):
1 2 3 4 5 6 7 8 9 10 11 12
doctrine:
# ...
orm:
# ...
mappings:
# ...
SomeEntityNamespace:
type: annotation
dir: '%kernel.project_dir%/src/Entity'
is_bundle: false
prefix: App\Entity
alias: App
Detecting a Mapping Configuration Format
If the type
on the bundle configuration isn't set, the DoctrineBundle
will try to detect the correct mapping configuration format for the bundle.
DoctrineBundle will look for files matching *.orm.[FORMAT]
(e.g.
Post.orm.yaml
) in the configured dir
of your mapping (if you're mapping
a bundle, then dir
is relative to the bundle's directory).
The bundle looks for (in this order) XML, YAML and PHP files.
Using the auto_mapping
feature, every bundle can have only one
configuration format. The bundle will stop as soon as it locates one.
If it wasn't possible to determine a configuration format for a bundle,
the DoctrineBundle will check if there is an Entity
folder in the bundle's
root directory. If the folder exist, Doctrine will fall back to using an
annotation driver.
Default Value of Dir
If dir
is not specified, then its default value depends on which configuration
driver is being used. For drivers that rely on the PHP files (annotation,
staticphp
) it will be [Bundle]/Entity
. For drivers that are using
configuration files (XML, YAML, ...) it will be
[Bundle]/Resources/config/doctrine
.
If the dir
configuration is set and the is_bundle
configuration
is true
, the DoctrineBundle will prefix the dir
configuration with
the path of the bundle.