Merge branch 'master' of github.com:doctrine/orm-documentation
This commit is contained in:
commit
d835372e93
@ -224,6 +224,33 @@ The following example sets up such a unidirectional one-to-many association:
|
|||||||
> **NOTE**
|
> **NOTE**
|
||||||
> One-To-Many uni-directional relations with join-table only work using the @ManyToMany annotation and a unique-constraint.
|
> One-To-Many uni-directional relations with join-table only work using the @ManyToMany annotation and a unique-constraint.
|
||||||
|
|
||||||
|
++ Many-To-One, Unidirectional
|
||||||
|
|
||||||
|
You can easily implement a many-to-one unidirectional association with the following:
|
||||||
|
|
||||||
|
[php]
|
||||||
|
/** @Entity */
|
||||||
|
class User
|
||||||
|
{
|
||||||
|
// ...
|
||||||
|
|
||||||
|
/**
|
||||||
|
* @ManyToOne(targetEntity="Address")
|
||||||
|
* @JoinColumn(name="address_id", referencedColumnName="id")
|
||||||
|
*/
|
||||||
|
private $address
|
||||||
|
}
|
||||||
|
|
||||||
|
/** @Entity */
|
||||||
|
class Address
|
||||||
|
{
|
||||||
|
// ...
|
||||||
|
}
|
||||||
|
|
||||||
|
> **TIP**
|
||||||
|
> The above `@JoinColumn` is optional as it would default to `address_id` and `id`
|
||||||
|
> anyways. You can omit it and let it use the defaults.
|
||||||
|
|
||||||
++ One-To-Many, Bidirectional
|
++ One-To-Many, Bidirectional
|
||||||
|
|
||||||
Bidirectional one-to-many associations are very common. The following code shows an example with a Product and a Feature class:
|
Bidirectional one-to-many associations are very common. The following code shows an example with a Product and a Feature class:
|
||||||
|
@ -343,17 +343,15 @@ objects in an ORM with transparent persistence.
|
|||||||
|
|
||||||
Doctrine, by default, does not allow partial objects. That means, any query that only selects partial object data and wants to retrieve the result as objects
|
Doctrine, by default, does not allow partial objects. That means, any query that only selects partial object data and wants to retrieve the result as objects
|
||||||
(i.e. `Query#getResult()`) will raise an exception telling you that
|
(i.e. `Query#getResult()`) will raise an exception telling you that
|
||||||
partial objects are dangerous. If you want to force a query to return you partial objects, possibly as a performance tweak, you can use the `Query#HINT_FORCE_PARTIAL_LOAD` query hint as follows:
|
partial objects are dangerous. If you want to force a query to return you partial objects, possibly as a performance tweak, you can use the `partial` keyword as follows:
|
||||||
|
|
||||||
[php]
|
[php]
|
||||||
$q = $em->createQuery("select u.id, u.name from MyApp\Domain\User u");
|
$q = $em->createQuery("select partial u.{id,name} from MyApp\Domain\User u");
|
||||||
$q->setHint(Query::HINT_FORCE_PARTIAL_LOAD, true);
|
|
||||||
|
|
||||||
+++ When should I force partial objects?
|
+++ When should I force partial objects?
|
||||||
|
|
||||||
Mainly for optimization purposes, especially since the stateless nature of PHP
|
Mainly for optimization purposes, but be careful of premature optimization as partial objects
|
||||||
applications means that any fields or objects that are loaded unnecessarily in
|
lead to potentially more fragile code.
|
||||||
a request are useless (though often minimal) overhead. Be careful of premature optimization. Only force partial objects if it proves to provide an improvement to a performance problem.
|
|
||||||
|
|
||||||
++ Proxy Objects
|
++ Proxy Objects
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user