1
0
mirror of synced 2024-12-14 23:26:04 +03:00

Merge branch 'master' of github.com:doctrine/orm-documentation

This commit is contained in:
Benjamin Eberlei 2010-05-01 03:38:27 +02:00
commit d835372e93
2 changed files with 31 additions and 6 deletions

View File

@ -224,6 +224,33 @@ The following example sets up such a unidirectional one-to-many association:
> **NOTE**
> 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
Bidirectional one-to-many associations are very common. The following code shows an example with a Product and a Feature class:

View File

@ -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
(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]
$q = $em->createQuery("select u.id, u.name from MyApp\Domain\User u");
$q->setHint(Query::HINT_FORCE_PARTIAL_LOAD, true);
$q = $em->createQuery("select partial u.{id,name} from MyApp\Domain\User u");
+++ When should I force partial objects?
Mainly for optimization purposes, especially since the stateless nature of PHP
applications means that any fields or objects that are loaded unnecessarily in
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.
Mainly for optimization purposes, but be careful of premature optimization as partial objects
lead to potentially more fragile code.
++ Proxy Objects