Navigation

We try to make using Doctrine2 a very pleasant experience.
Therefore we think it is very important to be honest about the
current limitations to our users. Much like every other piece of
software Doctrine2 is not perfect and far from feature complete.
This section should give you an overview of current limitations of
Doctrine 2 as well as critical known issues that you should know
about.

It is not possible to use join columns pointing to non-primary keys. Doctrine will think these are the primary
keys and create lazy-loading proxies with the data, which can lead to unexpected results. Doctrine can for performance
reasons not validate the correctness of this settings at runtime but only through the Validate Schema command.

Related to the previous limitation with “Foreign Keys as
Identifier” you might be interested in mapping the same table
structure as given above to an array. However this is not yet
possible either. See the following example:

A Persister in Doctrine is an object that is responsible for the
hydration and write operations of an entity against the database.
Currently there is no way to overwrite the persister implementation
for a given entity, however there are several use-cases that can
benefit from custom persister implementations:

PHP Arrays are ordered hash-maps and so should be the
Doctrine\Common\Collections\Collection interface. We plan to
evaluate a feature that optionally persists and hydrates the keys
of a Collection instance.

It is not possible to map several equally looking tables onto one
entity. For example if you have a production and an archive table
of a certain business concept then you cannot have both tables map
to the same entity.

Doctrine 2 will never include a behavior system like Doctrine 1
in the core library. We don’t think behaviors add more value than
they cost pain and debugging hell. Please see the many different
blog posts we have written on this topics:

Doctrine 2 has enough hooks and extension points so that you can
add whatever you want on top of it. None of this will ever become
core functionality of Doctrine2 however, you will have to rely on
third party extensions for magical behaviors.

NestedSet was offered as a behavior in Doctrine 1 and will not be
included in the core of Doctrine 2. However there are already two
extensions out there that offer support for Nested Set with
Doctrine 2:

The Known Issues section describes critical/blocker bugs and other
issues that are either complicated to fix, not fixable due to
backwards compatibility issues or where no simple fix exists (yet).
We don’t plan to add every bug in the tracker there, just those
issues that can potentially cause nightmares or pain of any sort.

For compatibility reasons between all the supported vendors and
edge case problems Doctrine 2 does NOT do automatic identifier
quoting. This can lead to problems when trying to get
legacy-databases to work with Doctrine 2.

You cannot use non [a-zA-Z0-9_]+ characters, they will break
several SQL statements.

Having problems with these kind of column names? Many databases
support all CRUD operations on views that semantically map to
certain tables. You can create views for all your problematic
tables and column names to avoid the legacy quoting nightmare.

Doctrine cannot provide atomic operations when calling EntityManager#flush() if one
of the tables involved uses the storage engine MyISAM. You must use InnoDB or
other storage engines that support transactions if you need integrity.