Fixed several issues and merged pull requests into docs.
This commit is contained in:
parent
126e592758
commit
22ab3d1256
@ -494,7 +494,7 @@ Example:
|
|||||||
|
|
||||||
<?php
|
<?php
|
||||||
/**
|
/**
|
||||||
* @ManyToOne(targetEntity="Cart", cascade={"ALL"}, fetch="EAGER")
|
* @ManyToOne(targetEntity="Cart", cascade={"all"}, fetch="EAGER")
|
||||||
*/
|
*/
|
||||||
private $cart;
|
private $cart;
|
||||||
|
|
||||||
|
@ -483,6 +483,6 @@ Ways exist to work around this, like pre-populating your cache and
|
|||||||
not letting your users requests populate the cache.
|
not letting your users requests populate the cache.
|
||||||
|
|
||||||
You can read more about cache slams
|
You can read more about cache slams
|
||||||
`in this blog post <http://t3.dotgnu.info/blog/php/user-cache-timebomb>`_.
|
`in this blog post <http://notmysock.org/blog/php/user-cache-timebomb.html>`_.
|
||||||
|
|
||||||
|
|
||||||
|
@ -30,8 +30,8 @@ Deferred Explicit
|
|||||||
|
|
||||||
The deferred explicit policy is similar to the deferred implicit
|
The deferred explicit policy is similar to the deferred implicit
|
||||||
policy in that it detects changes through a property-by-property
|
policy in that it detects changes through a property-by-property
|
||||||
comparison at commit time. The difference is that only entities are
|
comparison at commit time. The difference is that Doctrine 2 only
|
||||||
considered that have been explicitly marked for change detection
|
considers entities that have been explicitly marked for change detection
|
||||||
through a call to EntityManager#persist(entity) or through a save
|
through a call to EntityManager#persist(entity) or through a save
|
||||||
cascade. All other entities are skipped. This policy therefore
|
cascade. All other entities are skipped. This policy therefore
|
||||||
gives improved performance for larger units of work while
|
gives improved performance for larger units of work while
|
||||||
|
@ -35,7 +35,7 @@ object model.
|
|||||||
DQL SELECT statements are a very powerful way of retrieving parts
|
DQL SELECT statements are a very powerful way of retrieving parts
|
||||||
of your domain model that are not accessible via associations.
|
of your domain model that are not accessible via associations.
|
||||||
Additionally they allow to retrieve entities and their associations
|
Additionally they allow to retrieve entities and their associations
|
||||||
in one single sql select statement which can make a huge difference
|
in one single SQL select statement which can make a huge difference
|
||||||
in performance in contrast to using several queries.
|
in performance in contrast to using several queries.
|
||||||
|
|
||||||
DQL UPDATE and DELETE statements offer a way to execute bulk
|
DQL UPDATE and DELETE statements offer a way to execute bulk
|
||||||
@ -67,7 +67,7 @@ Lets examine the query:
|
|||||||
- ``u`` is a so called identification variable or alias that
|
- ``u`` is a so called identification variable or alias that
|
||||||
refers to the ``MyProject\Model\User`` class. By placing this alias
|
refers to the ``MyProject\Model\User`` class. By placing this alias
|
||||||
in the SELECT clause we specify that we want all instances of the
|
in the SELECT clause we specify that we want all instances of the
|
||||||
User class that are matched by this query appear in the query
|
User class that are matched by this query to appear in the query
|
||||||
result.
|
result.
|
||||||
- The FROM keyword is always followed by a fully-qualified class
|
- The FROM keyword is always followed by a fully-qualified class
|
||||||
name which in turn is followed by an identification variable or
|
name which in turn is followed by an identification variable or
|
||||||
@ -160,7 +160,7 @@ with numbers, for example "?1", "?2" and so on. Named parameters
|
|||||||
are specified with ":name1", ":name2" and so on.
|
are specified with ":name1", ":name2" and so on.
|
||||||
|
|
||||||
When referencing the parameters in ``Query#setParameter($param, $value)``
|
When referencing the parameters in ``Query#setParameter($param, $value)``
|
||||||
both named and positional parameters are used **without** their prefixies.
|
both named and positional parameters are used **without** their prefixes.
|
||||||
|
|
||||||
DQL SELECT Examples
|
DQL SELECT Examples
|
||||||
~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~
|
||||||
@ -208,7 +208,7 @@ Retrieve the Username and Name of a CmsUser:
|
|||||||
|
|
||||||
<?php
|
<?php
|
||||||
$query = $em->createQuery('SELECT u.username, u.name FROM CmsUser u');
|
$query = $em->createQuery('SELECT u.username, u.name FROM CmsUser u');
|
||||||
$users = $query->getResults(); // array of CmsUser username and id values
|
$users = $query->getResults(); // array of CmsUser username and name values
|
||||||
echo $users[0]['username'];
|
echo $users[0]['username'];
|
||||||
|
|
||||||
Retrieve a ForumUser and his single associated entity:
|
Retrieve a ForumUser and his single associated entity:
|
||||||
@ -268,7 +268,7 @@ With WHERE Clause and Named Parameter:
|
|||||||
|
|
||||||
<?php
|
<?php
|
||||||
$query = $em->createQuery('SELECT u FROM ForumUser u WHERE u.username = :name');
|
$query = $em->createQuery('SELECT u FROM ForumUser u WHERE u.username = :name');
|
||||||
$query->setParameter(':name', 'Bob');
|
$query->setParameter('name', 'Bob');
|
||||||
$users = $query->getResult(); // array of ForumUser objects
|
$users = $query->getResult(); // array of ForumUser objects
|
||||||
|
|
||||||
With Nested Conditions in WHERE Clause:
|
With Nested Conditions in WHERE Clause:
|
||||||
@ -278,9 +278,9 @@ With Nested Conditions in WHERE Clause:
|
|||||||
<?php
|
<?php
|
||||||
$query = $em->createQuery('SELECT u from ForumUser u WHERE (u.username = :name OR u.username = :name2) AND u.id = :id');
|
$query = $em->createQuery('SELECT u from ForumUser u WHERE (u.username = :name OR u.username = :name2) AND u.id = :id');
|
||||||
$query->setParameters(array(
|
$query->setParameters(array(
|
||||||
':name' => 'Bob',
|
'name' => 'Bob',
|
||||||
':name2' => 'Alice',
|
'name2' => 'Alice',
|
||||||
':id' => 321,
|
'id' => 321,
|
||||||
));
|
));
|
||||||
$users = $query->getResult(); // array of ForumUser objects
|
$users = $query->getResult(); // array of ForumUser objects
|
||||||
|
|
||||||
@ -384,7 +384,7 @@ Get all users who are members of $group.
|
|||||||
|
|
||||||
<?php
|
<?php
|
||||||
$query = $em->createQuery('SELECT u.id FROM CmsUser u WHERE :groupId MEMBER OF u.groups');
|
$query = $em->createQuery('SELECT u.id FROM CmsUser u WHERE :groupId MEMBER OF u.groups');
|
||||||
$query->setParameter(':groupId', $group);
|
$query->setParameter('groupId', $group);
|
||||||
$ids = $query->getResult();
|
$ids = $query->getResult();
|
||||||
|
|
||||||
Get all users that have more than 1 phonenumber
|
Get all users that have more than 1 phonenumber
|
||||||
@ -915,12 +915,12 @@ structure:
|
|||||||
.. code-block:: php
|
.. code-block:: php
|
||||||
|
|
||||||
array
|
array
|
||||||
array
|
[0]
|
||||||
[0] => Object
|
[0] => Object
|
||||||
[1] => "some scalar string"
|
[1] => "some scalar string"
|
||||||
['count'] => 42
|
['count'] => 42
|
||||||
// ... more scalar values, either indexed numerically or with a name
|
// ... more scalar values, either indexed numerically or with a name
|
||||||
array
|
[1]
|
||||||
[0] => Object
|
[0] => Object
|
||||||
[1] => "some scalar string"
|
[1] => "some scalar string"
|
||||||
['count'] => 42
|
['count'] => 42
|
||||||
|
@ -201,8 +201,8 @@ listeners:
|
|||||||
All Lifecycle events that happen during the ``flush()`` of
|
All Lifecycle events that happen during the ``flush()`` of
|
||||||
an EntityManager have very specific constraints on the allowed
|
an EntityManager have very specific constraints on the allowed
|
||||||
operations that can be executed. Please read the
|
operations that can be executed. Please read the
|
||||||
*Implementing Event Listeners* section very carefully to understand
|
:ref:`reference-events-implementing-listeners` section very carefully
|
||||||
which operations are allowed in which lifecycle event.
|
to understand which operations are allowed in which lifecycle event.
|
||||||
|
|
||||||
|
|
||||||
Lifecycle Callbacks
|
Lifecycle Callbacks
|
||||||
@ -361,6 +361,8 @@ EntityManager was created:
|
|||||||
$entityManager->getEventManager()->addEventListener(array(Events::preUpdate), MyEventListener());
|
$entityManager->getEventManager()->addEventListener(array(Events::preUpdate), MyEventListener());
|
||||||
$entityManager->getEventManager()->addEventSubscriber(new MyEventSubscriber());
|
$entityManager->getEventManager()->addEventSubscriber(new MyEventSubscriber());
|
||||||
|
|
||||||
|
.. _reference-events-implementing-listeners:
|
||||||
|
|
||||||
Implementing Event Listeners
|
Implementing Event Listeners
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
|
@ -199,6 +199,7 @@ a querybuilder instance into a Query object:
|
|||||||
|
|
||||||
.. code-block:: php
|
.. code-block:: php
|
||||||
|
|
||||||
|
<?php
|
||||||
// $qb instanceof QueryBuilder
|
// $qb instanceof QueryBuilder
|
||||||
$query = $qb->getQuery();
|
$query = $qb->getQuery();
|
||||||
|
|
||||||
|
@ -29,7 +29,7 @@ Association Example Entities
|
|||||||
We will use a simple comment system with Users and Comments as
|
We will use a simple comment system with Users and Comments as
|
||||||
entities to show examples of association management. See the PHP
|
entities to show examples of association management. See the PHP
|
||||||
docblocks of each association in the following example for
|
docblocks of each association in the following example for
|
||||||
information about its type and if its the owning or inverse side.
|
information about its type and if it's the owning or inverse side.
|
||||||
|
|
||||||
.. code-block:: php
|
.. code-block:: php
|
||||||
|
|
||||||
@ -398,7 +398,7 @@ can show the possible caveats you can encounter:
|
|||||||
$user->getFavorites()->contains($favoriteComment); // TRUE
|
$user->getFavorites()->contains($favoriteComment); // TRUE
|
||||||
$favoriteComment->getUserFavorites()->contains($user); // FALSE
|
$favoriteComment->getUserFavorites()->contains($user); // FALSE
|
||||||
|
|
||||||
There are to approaches to handle this problem in your code:
|
There are two approaches to handle this problem in your code:
|
||||||
|
|
||||||
|
|
||||||
1. Ignore updating the inverse side of bidirectional collections,
|
1. Ignore updating the inverse side of bidirectional collections,
|
||||||
@ -413,7 +413,7 @@ Transitive persistence / Cascade Operations
|
|||||||
-------------------------------------------
|
-------------------------------------------
|
||||||
|
|
||||||
Persisting, removing, detaching and merging individual entities can
|
Persisting, removing, detaching and merging individual entities can
|
||||||
become pretty cumbersome, especially when a larger object graph
|
become pretty cumbersome, especially when a large object graph
|
||||||
with collections is involved. Therefore Doctrine 2 provides a
|
with collections is involved. Therefore Doctrine 2 provides a
|
||||||
mechanism for transitive persistence through cascading of these
|
mechanism for transitive persistence through cascading of these
|
||||||
operations. Each association to another entity or a collection of
|
operations. Each association to another entity or a collection of
|
||||||
@ -531,7 +531,8 @@ OrphanRemoval works with both one-to-one and one-to-many associations.
|
|||||||
|
|
||||||
When using the ``orphanRemoval=true`` option Doctrine makes the assumption
|
When using the ``orphanRemoval=true`` option Doctrine makes the assumption
|
||||||
that the entities are privately owned and will **NOT** be reused by other entities.
|
that the entities are privately owned and will **NOT** be reused by other entities.
|
||||||
If you neglect this assumption your entities will get deleted by Doctrine anyways.
|
If you neglect this assumption your entities will get deleted by Doctrine even if
|
||||||
|
you assigned the orphaned entity to another one.
|
||||||
|
|
||||||
As a better example consider an Addressbook application where you have Contacts, Addresses
|
As a better example consider an Addressbook application where you have Contacts, Addresses
|
||||||
and StandingData:
|
and StandingData:
|
||||||
@ -588,5 +589,5 @@ Now two examples what happens when you remove the references:
|
|||||||
|
|
||||||
In this case you have only changed the ``Contact`` entity but you removed
|
In this case you have only changed the ``Contact`` entity but you removed
|
||||||
the references for standing data and one address reference. When flush is called
|
the references for standing data and one address reference. When flush is called
|
||||||
not only are the references removed also both the old standing data and the one address entity
|
not only are the references removed but both the old standing data and the one
|
||||||
are deleted from the database.
|
address entity are also deleted from the database.
|
Loading…
x
Reference in New Issue
Block a user