fixed typos and grammar

manual/en/improving-performance.txt

@@ -4,14 +4,14 @@
 It is highly recommended to make use of a bytecode cache like APC. A bytecode cache removes the need for parsing PHP code on every request and can greatly improve performance.
 
 > **NOTE**
-> "If you care about performance and don’t use a bytecode cache then you don’t really care
+> "If you care about performance and don't use a bytecode cache then you don't really care
 > about performance. Please get one and start using it." (Stas Malyshev, Core Contributor
 > to PHP and Zend Employee).
 
 
 ++ Metadata and Query caches
 
-As already mentioned earlier in the chapter about configuring Doctrine, it is strongly discouraged to use Doctrine without a Metadata and Query cache (preferrably with APC or Memcache as the cache driver). Operating Doctrine without these caches means Doctrine will need to load your mapping information on every single request and has to parse each DQL query on every single request. This is a waste of resources.
+As already mentioned earlier in the chapter about configuring Doctrine, it is strongly discouraged to use Doctrine without a Metadata and Query cache (preferably with APC or Memcache as the cache driver). Operating Doctrine without these caches means Doctrine will need to load your mapping information on every single request and has to parse each DQL query on every single request. This is a waste of resources.
 
 ++ Alternative Query Result Formats
 

manual/en/inheritance-mapping.txt

@@ -9,7 +9,7 @@ mapped inheritance hierarchy (through Single Table Inheritance or Class Table In
 
 > **NOTE**
 >
-> A mapped superclass cannot be an entity, it is not queryable and persistent relationships defined by a mapped
+> A mapped superclass cannot be an entity, it is not query-able and persistent relationships defined by a mapped
 > superclass must be unidirectional. For further support of inheritance, the single or joined table inheritance
 > features have to be used.
 

manual/en/limitations-and-known-issues.txt

@@ -138,7 +138,7 @@ as this is a pretty important feature we plan to add support for it in the futur
 
 +++ Custom Persisters
 
-A Perister in Doctrine is an object that is responsible for the hydration and write operations of an entity against the database.
+A Persister in Doctrine is an object that is responsible for the hydration and write operations of an entity against the database.
 Currently there is no way to overwrite the persister implementation for a given entity, however there are several use-cases that
 can benefit from custom persister implementations:
 

manual/en/metadata-drivers.txt

@@ -14,7 +14,7 @@ Doctrine provides a few different ways for you to specify your metadata:
 Something important to note about the above drivers is they are all an intermediate
 step to the same end result. The mapping information is populated to 
 `Doctrine\ORM\Mapping\ClassMetadata` instances. So in the end, Doctrine
-only ever has to work with the api of the `ClassMetadata` class to get mapping
+only ever has to work with the API of the `ClassMetadata` class to get mapping
 information for an entity.
 
 > **TIP**

manual/en/native-sql.txt

@@ -18,7 +18,7 @@ A Doctrine result can contain the following components:
  * Entity results. These represent root result elements.
  * Joined entity results. These represent joined entities in associations of root entity results.
  * Field results. These represent a column in the result set that maps to a field of an entity. A field result always belongs to an entity result or joined entity result.
- * Scalar results. These represent scalar values in the result set that will appear in each result row. Adding scalar results to a ResultSetMapping can also cause the overall result to becomed **mixed** (see DQL - Doctrine Query Language) if the same ResultSetMapping also contains entity results.
+ * Scalar results. These represent scalar values in the result set that will appear in each result row. Adding scalar results to a ResultSetMapping can also cause the overall result to become **mixed** (see DQL - Doctrine Query Language) if the same ResultSetMapping also contains entity results.
  * Meta results. These represent columns that contain meta-information, such as foreign keys and discriminator columns. 
    When querying for objects (`getResult()`), all meta columns of root entities or joined entities must be present in the SQL query
    and mapped accordingly using `ResultSetMapping#addMetaResult`.

manual/en/partial-objects.txt

@@ -21,7 +21,7 @@ right? These blind assumptions can quickly lead to null reference errors when
 working with such partial objects.
 
 It gets worse with the scenario of an optional association (0..1 to 1). When
-the associated field is NULL, you dont know whether this object does not have
+the associated field is NULL, you don't know whether this object does not have
 an associated object or whether it was simply not loaded when the owning object
 was loaded from the database.
 

manual/en/query-builder.txt

@@ -3,7 +3,7 @@
 
 A `QueryBuilder` provides an API that is designed for conditionally constructing a DQL query in several steps.
 
-It provides a set of classes and methods that is able to programatically build you queries, and also provides a fluent API.
+It provides a set of classes and methods that is able to programmatically build queries, and also provides a fluent API.
 This means that you can change between one methodology to the other as you want, and also pick one if you prefer.
 
 +++ Constructing a new QueryBuilder object
@@ -17,7 +17,7 @@ Here is an example how to build a `QueryBuilder` object:
     // example1: creating a QueryBuilder instance
     $qb = $em->createQueryBuilder();
     
-Once you created an instance of QueryBuilder, it provides a set of useful informative functions that you can use.
+Once you have created an instance of QueryBuilder, it provides a set of useful informative functions that you can use.
 One good example is to inspect what type of object the `QueryBuilder` is.
 
     [php]
@@ -46,16 +46,16 @@ It is possible to retrieve the associated `EntityManager` of the current `QueryB
     // example5: retrieve the associated Query object with the processed DQL
     $q = $qb->getQuery();
     
-Internally, `QueryBuilder` works with a DQL cache, which prevents multiple processment if called multiple times. Any changes that may affect the generated DQL actually modifies the state of `QueryBuilder` to a stage we call as STATE_DIRTY.
-One `QueryBuilder`can be in two different state:
+Internally, `QueryBuilder` works with a DQL cache to increase performance. Any changes that may affect the generated DQL actually modifies the state of `QueryBuilder` to a stage we call STATE_DIRTY.
+One `QueryBuilder` can be in two different states:
 
 * `QueryBuilder::STATE_CLEAN`, which means DQL haven't been altered since last retrieval or nothing were added since its instantiation
 * `QueryBuilder::STATE_DIRTY`, means DQL query must (and will) be processed on next retrieval
     
 +++ Working with QueryBuilder
 
-All helper methods in `QueryBuilder` relies actually on a single one: `add()`.
-This method is the responsable to build every piece of DQL. It takes 3 parameters: `$dqlPartName`, `$dqlPart` and `$append` (default=false)
+All helper methods in `QueryBuilder` actually rely on a single one: `add()`.
+This method is responsible of building every piece of DQL. It takes 3 parameters: `$dqlPartName`, `$dqlPart` and `$append` (default=false)
 
 * `$dqlPartName`: Where the `$dqlPart` should be placed. Possible values: select, from, where, groupBy, having, orderBy
 * `$dqlPart`: What should be placed in `$dqlPartName`. Accepts a string or any instance of `Doctrine\ORM\Query\Expr\*`
@@ -110,7 +110,7 @@ If you've got several parameters to bind to your query, you can also use setPara
     $qb->setParameters(array(1 => 'value for ?1', 2 => 'value for ?2'));
 
 
-Getting already bound parameters is easy - simply use the abovementioned syntax with "getParameter()" or "getParameters()":
+Getting already bound parameters is easy - simply use the above mentioned syntax with "getParameter()" or "getParameters()":
 
     [php]
     // $qb instanceof QueryBuilder
@@ -155,7 +155,7 @@ This class is called `Expr`, which provides a set of useful static methods to he
        ))
        ->add('orderBy', $qb->expr()->orderBy('u.surname', 'ASC'));
        
-Although it still sounds complex, the ability to programatically create conditions are the main feature of `Expr`.
+Although it still sounds complex, the ability to programmatically create conditions are the main feature of `Expr`.
 Here it is a complete list of supported helper methods available:
 
     [php]
@@ -305,9 +305,9 @@ Here it is a complete list of supported helper methods available:
 
 ++++ Helper methods
 
-Until now it was described the hardcore level of creating queries. It may be useful to work that way for optimization purposes, but most of the time it is preferred to work higher level.
-To simplify even more the way you build a query in Doctrine, we can take advantage of what we call as helper methods. For all base code, it has a set of useful methods to simplify programmer's life.
-Illustrating how to work with it, here is the same example 6 written now using `QueryBuilder` helper methods:
+Until now we have described the lowest level (thought of as the hardcore method) of creating queries. It may be useful to work at this level for optimization purposes, but most of the time it is preferred to work at a higher level of abstraction.
+To simplify even more the way you build a query in Doctrine, we can take advantage of what we call Helper methods. For all base code, there is a set of useful methods to simplify a programmer's life.
+To illustrate how to work with them, here is the same example 6 re-written using `QueryBuilder` helper methods:
 
     [php]
     // $qb instanceof QueryBuilder
@@ -333,7 +333,7 @@ Here is a converted example 8 to suggested standard way to build queries:
        ))
        ->orderBy('u.surname', 'ASC'));
 
-Here is a complete list of helper methods in `QueryBuilder`:
+Here is a complete list of helper methods available in `QueryBuilder`:
 
     [php]
     class QueryBuilder
@@ -378,7 +378,7 @@ Here is a complete list of helper methods in `QueryBuilder`:
         // Example - $qb->orWhere($qb->expr()->between('u.id', 1, 10));
         public function orWhere($where);
 
-        // NOTE: -> groupBy() overrides all previously set grouping items
+        // NOTE: -> groupBy() overrides all previously set grouping conditions
         //
         // Example - $qb->groupBy('u.id')   
         public function groupBy($groupBy);
@@ -398,7 +398,7 @@ Here is a complete list of helper methods in `QueryBuilder`:
         // Example - $qb->orHaving($qb->expr()->lte('g.managerLevel', '100'))    
         public function orHaving($having);
     
-        // NOTE: -> orderBy() overrides all previously set ordering items
+        // NOTE: -> orderBy() overrides all previously set ordering conditions
         //
         // Example - $qb->orderBy('u.surname', 'DESC')
         public function orderBy($sort, $order = null);

manual/en/tools.txt

@@ -38,7 +38,7 @@ When dealing with the ORM package, the EntityManagerHelper is required:
     ));
     $cli->setHelperSet($helperSet);
 
-The HelperSet instance has to be generated in a separate file (ie. `cli-config.php`) that contains typical Doctrine
+The HelperSet instance has to be generated in a separate file (i.e. `cli-config.php`) that contains typical Doctrine
 bootstrap code and predefines the needed HelperSet attributes mentioned above. A typical `cli-config.php` file looks as follows:
 
     [php]
@@ -140,7 +140,7 @@ To drop the schema you can use the `dropSchema()` method.
     $tool->dropSchema($classes);
 
 This drops all the tables that are currently used by your metadata model.
-When you are changing your metadata alot during development you might want
+When you are changing your metadata a lot during development you might want
 to drop the complete database instead of only the tables of the current model
 to clean up with orphaned tables.
 
@@ -185,7 +185,7 @@ Before using the orm:schema-tool commands, remember to configure your cli-config
 >
 > When using the Annotation Mapping Driver you have to either setup your autoloader in the cli-config.php
 > correctly to find all the entities, or you can use the second argument of the `EntityManagerHelper` to
-> specifiy all the paths of your entities (or mapping files), i.e.
+> specify all the paths of your entities (or mapping files), i.e.
 > `new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em, $mappingPaths);`
 
 ++ Convert Mapping Information

manual/en/transactions-and-concurrency.txt

@@ -10,7 +10,7 @@ For the most part, Doctrine 2 already takes care of proper transaction demarcati
 operations (INSERT/UPDATE/DELETE) are queued until `EntityManager#flush()` is invoked which wraps all
 of these changes in a single transaction.
 
-However, Doctrine 2 also allows (and ecourages) you to take over and control transaction demarcation yourself.
+However, Doctrine 2 also allows (and encourages) you to take over and control transaction demarcation yourself.
 
 These are two ways to deal with transactions when using the Doctrine ORM and are now described in more detail.
 
@@ -85,10 +85,10 @@ is automatically rolled back and the `EntityManager` closed.
 When using explicit transaction demarcation and an exception occurs, the transaction should be rolled back immediately
 and the `EntityManager` closed by invoking `EntityManager#close()` and subsequently discarded, as demonstrated in
 the example above. This can be handled elegantly by the control abstractions shown earlier.
-Note that when catching `Exception` you should generally rethrow the exception. If you intend to
+Note that when catching `Exception` you should generally re-throw the exception. If you intend to
 recover from some exceptions, catch them explicitly in earlier catch blocks (but do not forget to rollback the
 transaction and close the `EntityManager` there as well). All other best practices of exception handling apply
-similarly (i.e. either log or rethrow, not both, etc.).
+similarly (i.e. either log or re-throw, not both, etc.).
 
 As a result of this procedure, all previously managed or removed instances of the `EntityManager` become detached.
 The state of the detached objects will be the state at the point at which the transaction was rolled back.
@@ -96,7 +96,7 @@ The state of the objects is in no way rolled back and thus the objects are now o
 The application can continue to use the detached objects, knowing that their state is potentially no longer
 accurate.
 
-If you intend to start another unit of work after an exception has occured you should do that with a new `EntityManager`.
+If you intend to start another unit of work after an exception has occurred you should do that with a new `EntityManager`.
 
 ++ Locking Support
 
@@ -115,7 +115,7 @@ Doctrine has integrated support for automatic optimistic locking via a version f
 that should be protected against concurrent modifications during long-running business transactions gets a version
 field that is either a simple number (mapping type: integer) or a timestamp (mapping type: datetime). When changes
 to such an entity are persisted at the end of a long-running conversation the version of the entity is compared to
-the version in the database and if they dont match, an `OptimisticLockException` is thrown, indicating that the
+the version in the database and if they don't match, an `OptimisticLockException` is thrown, indicating that the
 entity has been modified by someone else already.
 
 You designate a version field in an entity as follows. In this example we'll use an integer.
@@ -229,12 +229,12 @@ And the change headline action (POST Request):
 +++ Pessimistic Locking
 
 Doctrine 2 supports Pessimistic Locking at the database level. No attempt is being made to implement pessimistic locking
-inside Doctrine, rather vendor-specific and ANSI-SQL commands are used to aquire row-level locks. Every Entity can
+inside Doctrine, rather vendor-specific and ANSI-SQL commands are used to acquire row-level locks. Every Entity can
 be part of a pessimistic lock, there is no special metadata required to use this feature.
 
 However for Pessimistic Locking to work you have to disable the Auto-Commit Mode of your Database and start a
 transaction around your pessimistic lock use-case using the "Approach 2: Explicit Transaction Demarcation" described
-above. Doctrine 2 will throw an Exception if you attempt to aquire an pessimistic lock and no transaction is running.
+above. Doctrine 2 will throw an Exception if you attempt to acquire an pessimistic lock and no transaction is running.
 
 Doctrine 2 currently supports two pessimistic lock modes:
 

manual/en/working-with-associations.txt

@@ -325,7 +325,7 @@ Using the User-Comment entities from above, a very simple example can show the p
     // not calling $favoriteComment->getUserFavorites()->add($user);
 
     $user->getFavorites()->contains($favoriteComment); // TRUE
-    $favoriteComment->getUerFavorites()->contains($user); // FALSE
+    $favoriteComment->getUserFavorites()->contains($user); // FALSE
 
 There are to approaches to handle this problem in your code:
 

manual/en/working-with-objects.txt

@@ -1,7 +1,7 @@
 
 In this chapter we will help you understand the `EntityManager` and the `UnitOfWork`. 
 A Unit of Work is similar to an object-level transaction. A new Unit of Work is 
-implicity started when an EntityManager is initially created or after 
+implicitly started when an EntityManager is initially created or after 
 `EntityManager#flush()` has been invoked. A Unit of Work is committed 
 (and a new one started) by invoking `EntityManager#flush()`.
 
@@ -213,7 +213,7 @@ The semantics of the remove operation, applied to an entity X are as follows:
 
 After an entity has been removed its in-memory state is the same as before the removal, except for generated identifiers.
 
-Removing an entity will also automatically delete any exisiting records in many-to-many
+Removing an entity will also automatically delete any existing records in many-to-many
 join tables that link this entity. The action taken depends on the value of the `@joinColumn`
 mapping attribute "onDelete". Either Doctrine issues a dedicated `DELETE` statement
 for records of each join table or it depends on the foreign key semantics of
@@ -234,7 +234,7 @@ ways with very different performance impacts.
 3. Using foreign key semantics `onDelete="CASCADE"` can force the database
    to remove all associated objects internally. This strategy is a bit
    tricky to get right but can be very powerful and fast. You should be aware
-   however that using strategy 1 (`CASCADE=REMOVE`) completly by-passes
+   however that using strategy 1 (`CASCADE=REMOVE`) completely by-passes
    any foreign key `onDelete=CASCADE` option, because Doctrine will fetch and remove
    all associated entities explicitly nevertheless.
 
@@ -300,7 +300,7 @@ MERGE or ALL, Y is merged recursively as Y'.  For all such Y referenced by X, X'
     
 The `merge` operation will throw an `OptimisticLockException` if the entity 
 being merged uses optimistic locking through a version field and the versions 
-of the entity being merged and the managed copy dont match. This usually means 
+of the entity being merged and the managed copy don't match. This usually means 
 that the entity has been modified while being detached.
 
 The `merge` operation is usually not as frequently needed and used as `persist` 
@@ -448,7 +448,7 @@ Essentially, `EntityManager#find()` is just a shortcut for the following:
     // $em instanceof EntityManager
     $user = $em->getRepository('MyProject\Domain\User')->find($id);
 
-`EntityManager#getRepository($entityName)` returns a repository object which provides many ways to retreive entities of the specified type. By default, the repository instance is of type `Doctrine\ORM\EntityRepository`. You can also use custom repository classes as shown later.
+`EntityManager#getRepository($entityName)` returns a repository object which provides many ways to retrieve entities of the specified type. By default, the repository instance is of type `Doctrine\ORM\EntityRepository`. You can also use custom repository classes as shown later.
 
 +++ By Simple Conditions
 
@@ -489,7 +489,7 @@ Whenever you have a managed entity instance at hand, you can traverse and use an
 +++ By DQL
 
 The most powerful and flexible method to query for persistent objects is the Doctrine Query Language, an object query language. DQL enables you to query for persistent objects in the language of objects. DQL understands classes, fields, inheritance and associations.
-DQL is syntactically very similar to the familar SQL but *it is not SQL*.
+DQL is syntactically very similar to the familiar SQL but *it is not SQL*.
 
 A DQL query is represented by an instance of the `Doctrine\ORM\Query` class. You create a query using `EntityManager#createQuery($dql)`. Here is a simple example:
 

manual/en/xml-mapping.txt

@@ -230,7 +230,7 @@ Optional attributes for `<sequence-generator />`:
 > **NOTE**
 >
 > If you want to implement a cross-vendor compatible application you have to specify <generator strategy="AUTO" /> and
-> additionaly define the <sequence-generator /> element, if Doctrine chooses the sequence strategy for a platform.
+> additionally define the <sequence-generator /> element, if Doctrine chooses the sequence strategy for a platform.
 
 +++ Defining a Mapped Superclass
 
@@ -256,7 +256,7 @@ a mapped superclass.
 +++ Defining Inheritance Mappings
 
 There are currently two inheritance persistence strategies that you can choose from when defining entities that
-inherit from each other. Single Table inheritance saves the fields of the complete inheritance hierachy in a single table,
+inherit from each other. Single Table inheritance saves the fields of the complete inheritance hierarchy in a single table,
 joined table inheritance creates a table for each entity combining the fields using join conditions.
 
 You can specify the inheritance type in the `<entity />` element and then use the `<discriminator-column />` and
@@ -276,7 +276,7 @@ The allowed values for inheritance-type attribute are `JOINED` or `SINGLE_TABLE`
 
 > **NOTE**
 >
-> All inheritance related definitions have to be defined on the root entity of the hierachy.
+> All inheritance related definitions have to be defined on the root entity of the hierarchy.
 
 +++ Defining Lifecycle Callbacks
 
@@ -292,7 +292,7 @@ You can define the lifecycle callback methods on your entities using the `<lifec
 
 +++ Defining One-To-One Relations
 
-You can define One-To-One Relations/Assocations using the `<one-to-one />` element. The required
+You can define One-To-One Relations/Associations using the `<one-to-one />` element. The required
 and optional attributes depend on the associations being on the inverse or owning side.
 
 For the inverse side the mapping is as simple as:
@@ -304,7 +304,7 @@ For the inverse side the mapping is as simple as:
 
 Required attributes for inverse One-To-One:
 
-* field - Name of the property/field on the entitys PHP class.
+* field - Name of the property/field on the entity's PHP class.
 * target-entity - Name of the entity associated entity class. If this is not qualified the namespace of the current class is prepended.
 * mapped-by - Name of the field on the owning side (here Address entity) that contains the owning side association.
 
@@ -317,7 +317,7 @@ For the owning side this mapping would look like:
 
 Required attributes for owning One-to-One:
 
-* field - Name of the property/field on the entitys PHP class.
+* field - Name of the property/field on the entity's PHP class.
 * target-entity - Name of the entity associated entity class. If this is not qualified the namespace of the current class is prepended.
 
 Optional attributes for owning One-to-One:
@@ -331,7 +331,7 @@ Without the nested `<join-column />` element Doctrine assumes to foreign key to
 Entities table. This is because the `MyProject\Address` entity is the owning side of this association, which means
 it contains the foreign key.
 
-The completed explictly defined mapping is:
+The completed explicitly defined mapping is:
 
     [xml]
     <entity class="MyProject\Address">
@@ -352,7 +352,7 @@ compared to the one-to-one case. The minimal mapping for this association looks
 
 Required attributes:
 
-* field - Name of the property/field on the entitys PHP class.
+* field - Name of the property/field on the entity's PHP class.
 * target-entity - Name of the entity associated entity class. If this is not qualified the namespace of the current class is prepended.
 
 Optional attributes:
@@ -362,7 +362,7 @@ Optional attributes:
 * fetch - Either LAZY or FETCH, defaults to LAZY.
 
 This definition relies on a bunch of mapping defaults with regards to the naming of the join-column/foreign key. The
-explictly defined mapping includes a `<join-column />` tag nested inside the many-to-one association tag:
+explicitly defined mapping includes a `<join-column />` tag nested inside the many-to-one association tag:
 
     [xml]
     <entity class="MyProject\Article">
@@ -387,7 +387,7 @@ uni-directional one-to-many association, which means this association only ever
 
 Required attributes:
 
-* field - Name of the property/field on the entitys PHP class.
+* field - Name of the property/field on the entity's PHP class.
 * target-entity - Name of the entity associated entity class. If this is not qualified the namespace of the current class is prepended.
 * mapped-by - Name of the field on the owning side (here Phonenumber entity) that contains the owning side association.
 
@@ -407,7 +407,7 @@ you can omit many definitions and rely on their implicit values.
 
 Required attributes:
 
-* field - Name of the property/field on the entitys PHP class.
+* field - Name of the property/field on the entity's PHP class.
 * target-entity - Name of the entity associated entity class. If this is not qualified the namespace of the current class is prepended.
 
 Optional attributes:
@@ -439,7 +439,7 @@ the table name of the many-to-many join-table.
 
 +++ Cascade Element
 
-Doctrine allows cascading of several UnitOfWork operations to related entities. You can specifiy the cascade
+Doctrine allows cascading of several UnitOfWork operations to related entities. You can specify the cascade
 operations in the `<cascade />` element inside any of the association mapping tags.
 
     [xml]
@@ -451,7 +451,7 @@ operations in the `<cascade />` element inside any of the association mapping ta
         </many-to-many>
     </entity>
 
-Besides `<cascade-all />` the following operations can be specifed by their respective tags:
+Besides `<cascade-all />` the following operations can be specified by their respective tags:
 
 * `<cascade-persist />`
 * `<cascade-merge />`