diff --git a/docs/en/cookbook/entities-in-session.rst b/docs/en/cookbook/entities-in-session.rst index 664cff53f5c..39bb1e13e4a 100644 --- a/docs/en/cookbook/entities-in-session.rst +++ b/docs/en/cookbook/entities-in-session.rst @@ -26,11 +26,11 @@ the session into a managed Doctrine object looks like this: merge($user); } @@ -44,7 +44,7 @@ Serializing entity into the session ----------------------------------- Entities that are serialized into the session normally contain references to -other entities as well. Think of the user entity has a reference to his +other entities as well. Think of the user entity has a reference to its articles, groups, photos or many other different entities. If you serialize this object into the session then you don't want to serialize the related entities as well. This is why you should call ``EntityManager#detach()`` on this @@ -54,7 +54,7 @@ object or implement the __sleep() magic method on your entity. find("User", 1); $em->detach($user); diff --git a/docs/en/cookbook/validation-of-entities.rst b/docs/en/cookbook/validation-of-entities.rst index dd10b8b9afa..7560a65d6e9 100644 --- a/docs/en/cookbook/validation-of-entities.rst +++ b/docs/en/cookbook/validation-of-entities.rst @@ -25,8 +25,8 @@ the additional benefit of being able to re-use your validation in any other part of your domain. Say we have an ``Order`` with several ``OrderLine`` instances. We -never want to allow any customer to order for a larger sum than he -is allowed to: +never want to allow any customer to order for a larger sum than they +are allowed to: .. code-block:: php diff --git a/docs/en/reference/dql-doctrine-query-language.rst b/docs/en/reference/dql-doctrine-query-language.rst index 5a38101be93..ffb5b7957b2 100644 --- a/docs/en/reference/dql-doctrine-query-language.rst +++ b/docs/en/reference/dql-doctrine-query-language.rst @@ -250,7 +250,7 @@ Retrieve the Username and Name of a CmsUser: $users = $query->getResult(); // array of CmsUser username and name values echo $users[0]['username']; -Retrieve a ForumUser and his single associated entity: +Retrieve a ForumUser and its single associated entity: .. code-block:: php @@ -259,7 +259,7 @@ Retrieve a ForumUser and his single associated entity: $users = $query->getResult(); // array of ForumUser objects with the avatar association loaded echo get_class($users[0]->getAvatar()); -Retrieve a CmsUser and fetch join all the phonenumbers he has: +Retrieve a CmsUser and fetch join all the phonenumbers it has: .. code-block:: php diff --git a/docs/en/reference/unitofwork-associations.rst b/docs/en/reference/unitofwork-associations.rst index c9ccf73fc8a..cade197cdc7 100644 --- a/docs/en/reference/unitofwork-associations.rst +++ b/docs/en/reference/unitofwork-associations.rst @@ -39,7 +39,7 @@ side of the association and these 2 references both represent the same association but can change independently of one another. Of course, in a correct application the semantics of the bidirectional association are properly maintained by the application developer -(that's his responsibility). Doctrine needs to know which of these +(that's their responsibility). Doctrine needs to know which of these two in-memory references is the one that should be persisted and which not. This is what the owning/inverse concept is mainly used for. diff --git a/docs/en/reference/unitofwork.rst b/docs/en/reference/unitofwork.rst index b060c464a17..4376118e1be 100644 --- a/docs/en/reference/unitofwork.rst +++ b/docs/en/reference/unitofwork.rst @@ -104,7 +104,7 @@ How Doctrine Detects Changes Doctrine is a data-mapper that tries to achieve persistence-ignorance (PI). This means you map php objects into a relational database that don't necessarily know about the database at all. A natural question would now be, -"how does Doctrine even detect objects have changed?". +"how does Doctrine even detect objects have changed?". For this Doctrine keeps a second map inside the UnitOfWork. Whenever you fetch an object from the database Doctrine will keep a copy of all the properties and @@ -148,8 +148,8 @@ Hydration ~~~~~~~~~ Responsible for creating a final result from a raw database statement and a -result-set mapping object. The developer can choose which kind of result he -wishes to be hydrated. Default result-types include: +result-set mapping object. The developer can choose which kind of result they +wish to be hydrated. Default result-types include: - SQL to Entities - SQL to structured Arrays diff --git a/docs/en/tutorials/getting-started.rst b/docs/en/tutorials/getting-started.rst index 52190e57099..1070b612c8d 100644 --- a/docs/en/tutorials/getting-started.rst +++ b/docs/en/tutorials/getting-started.rst @@ -72,7 +72,7 @@ requirements: - Bug reporters and engineers are both Users of the system. - A User can create new Bugs. - The assigned engineer can close a Bug. -- A User can see all his reported or assigned Bugs. +- A User can see all of their reported or assigned Bugs. - Bugs can be paginated through a list-view. Project Setup @@ -133,9 +133,9 @@ step: // bootstrap.php use Doctrine\ORM\Tools\Setup; use Doctrine\ORM\EntityManager; - + require_once "vendor/autoload.php"; - + // Create a simple "default" Doctrine ORM configuration for Annotations $isDevMode = true; $proxyDir = null; @@ -145,13 +145,13 @@ step: // or if you prefer yaml or XML //$config = Setup::createXMLMetadataConfiguration(array(__DIR__."/config/xml"), $isDevMode); //$config = Setup::createYAMLMetadataConfiguration(array(__DIR__."/config/yaml"), $isDevMode); - + // database configuration parameters $conn = array( 'driver' => 'pdo_sqlite', 'path' => __DIR__ . '/db.sqlite', ); - + // obtaining the entity manager $entityManager = EntityManager::create($conn, $config); @@ -193,7 +193,7 @@ defined entity classes and their metadata. For this tool to work, a