RetailCRM-Mirror/doctrine2
1
0
Fork 0
mirror of synced 2025-01-18 14:31:40 +03:00
Code Issues Projects Releases Wiki Activity

Add section about database and unit of work being out of sync and how this effects your code.

Browse Source
This commit is contained in:
Benjamin Eberlei 2010-12-11 01:01:44 +01:00
parent 01c2a09991
commit eb0fd4d066
2 changed files with 27 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
en/reference/dql-doctrine-query-language.rst
View File

@ -781,6 +781,7 @@ automatically for you:
SELECT p0_.id AS id0, p0_.name AS name1, e1_.department AS department2, p0_.discr AS discr3 FROM Employee e1_ INNER JOIN Person p0_ ON e1_.id = p0_.id WHERE p0_.name = ?
The Query class
---------------

28
en/reference/working-with-objects.rst
View File

@ -256,8 +256,12 @@ which means that its persistent state will be deleted once
Just like ``persist``, invoking ``remove`` on an entity
does NOT cause an immediate SQL DELETE to be issued on the
database. The entity will be deleted on the next invocation of
``EntityManager#flush()`` that involves that entity.
``EntityManager#flush()`` that involves that entity. This
means that entities scheduled for removal can still be queried
for and appear in query and collection results. See
the section on :ref:`Database and UnitOfWork Out-Of-Sync <workingobjects_database_uow_outofsync>`
for more information.
Example:
@ -465,6 +469,26 @@ When ``EntityManager#flush()`` is called, Doctrine inspects all
managed, new and removed entities and will perform the following
operations.
.. _workingobjects_database_uow_outofsync:
Effects of Database and UnitOfWork being Out-Of-Sync
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As soon as you begin to change the state ofentities, call persist or remove the
contents of the UnitOfWork and the database will drive out of sync. They can
only be sychronized by calling ``EntityManager#flush()`. This section
describes the effects of database and UnitOfWork being out of sync.
- Entities that are scheduled for removal can still be queried from the database.
They are returned from DQL and Repository queries and are visible in collections.
- Entities that are passed to ``EntityManager#persist`` do not turn up in query
results.
- Entities that have changed will not be overwritten with the state from the database.
This is because the identity map will detect the construction of an already existing
entity and assumes its the most up to date version.
``EntityManager#flush()`` is never called implicitly by Doctrine. You always have to trigger it manually.
Synchronizing New and Managed Entities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~