Merge pull request #3 from bantu/master

beberlei · beberlei · commit f61d41744dbd · 2011-11-10T11:18:09.000-08:00
Various minor improvements such as typo and grammar fixes etc.
diff --git a/en/reference/architecture.rst b/en/reference/architecture.rst
@@ -60,7 +60,7 @@ features a platform supports. The
 denominator of what a database platform has to publish to the
 userland, to be fully supportable by Doctrine. This includes the
 SchemaTool, Transaction Isolation and many other features. The
-Database platform for MySQL for example can be used by all 3 mysql
+Database platform for MySQL for example can be used by all 3 MySQL
 extensions, PDO, Mysqli and ext/mysql.
 
 Logging
diff --git a/en/reference/configuration.rst b/en/reference/configuration.rst
@@ -48,7 +48,7 @@ interfaces to use. It can be configured in one of three ways:
       extension.
       **Note that this driver caused problems in our tests. Prefer the oci8 driver if possible.**
    -  ``pdo_sqlsrv``: An MSSQL driver that uses pdo\_sqlsrv PDO
-   -  ``oci8``:\` An Oracle driver that uses the oci8 PHP extension.
+   -  ``oci8``: An Oracle driver that uses the oci8 PHP extension.
 
 -  ``driverClass``: Specifies a custom driver implementation if no
    'driver' is specified. This allows the use of custom drivers that
@@ -60,7 +60,7 @@ Wrapper Class
 
 By default a ``Doctrine\DBAL\Connection`` is wrapped around a
 driver ``Connection``. The ``wrapperClass`` option allows to
-specify a custom wrapper implementation to use, however, custom
+specify a custom wrapper implementation to use, however, a custom
 wrapper class must be a subclass of ``Doctrine\DBAL\Connection``.
 
 Connection Details
@@ -157,7 +157,7 @@ Custom Driver Options
 ~~~~~~~~~~~~~~~~~~~~~
 
 The ``driverOptions`` option allows to pass arbitrary options
-through to the driver. This is equivalent to the 4th argument of
+through to the driver. This is equivalent to the fourth argument of
 the `PDO constructor <http://php.net/manual/en/pdo.construct.php>`_.
 
 
diff --git a/en/reference/data-retrieval-and-manipulation.rst b/en/reference/data-retrieval-and-manipulation.rst
@@ -2,21 +2,21 @@ Data Retrieval And Manipulation
 ===============================
 
 Doctrine DBAL follows the PDO API very closely. If you have worked with PDO
-before you will get to know Doctrine DBAL very quickly. On top of API provided
+before you will get to know Doctrine DBAL very quickly. On top of the API provided
 by PDO there are tons of convenience functions in Doctrine DBAL.
 
 Data Retrieval
 --------------
 
-Using a database implies retrieval of data. Its the primary use-case of a database.
+Using a database implies retrieval of data. It is the primary use-case of a database.
 For this purpose each database vendor exposes a Client API that can be integrated into
-all the programming languages. PHP has a generic abstraction layer for this
-kind of Client API called PDO (PHP Data Objects). However because of disagreements
+programming languages. PHP has a generic abstraction layer for this
+kind of API called PDO (PHP Data Objects). However because of disagreements
 between the PHP community there are often native extensions for each database
 vendor that are much more maintained (OCI8 for example).
 
 Doctrine DBAL API builds on top of PDO and integrates native extensions by
-wrapping them into the PDO API aswell. If you already have an open connection
+wrapping them into the PDO API as well. If you already have an open connection
 through the ``Doctrine\DBAL\DriverManager::getConnection()`` method you
 can start using this API for data retrieval easily.
 
@@ -33,7 +33,7 @@ connection:
     $sql = "SELECT * FROM articles";
     $stmt = $conn->query($sql); // Simple, but has several drawbacks
 
-The query method executes and the sql and returns a database statement object.
+The query method executes the SQL and returns a database statement object.
 A database statement object can be iterated to retrieve all the rows that matched
 the query until there are no more rows:
 
@@ -49,15 +49,15 @@ The query method is the most simple one for fetching data, but it also has
 several drawbacks:
 
 -   There is no way to add dynamic parameters to the SQL query without modifying
-    the sql query (``$sql``) itself. This can easily lead to a category of security
+    ``$sql`` itself. This can easily lead to a category of security
     holes called **SQL injection**, where a third party can modify the SQL executed 
     and even execute their own queries through clever exploiting of the security hole.
 -   **Quoting** dynamic parameters for an SQL query is tedious work and requires lots
     of use of the ``Doctrine\DBAL\Connection#quote()`` method, which makes the
     original SQL query hard to read/understand.
--   Databases optimize the SQL query to be executed, using the query method
+-   Databases optimize SQL queries before they are executed. Using the query method
     you will trigger the optimization process over and over again, although
-    it could re-use this information easily using a technique called **prepared statement**.
+    it could re-use this information easily using a technique called **prepared statements**.
 
 This three arguments and some more technical details hopefully convinced you to investigate
 prepared statements for accessing your database. 
@@ -76,8 +76,8 @@ every value passed into the query using ``mysql_real_escape_string()`` to avoid
     $rs = mysql_query($sql);
 
 If you start adding more and more parameters to a query (for example in UPDATE or INSERT statements)
-this approach might lead to complex to maintain sql queries. The reason is simple, the actual
-sql query is not separated clearly from the input parameters. Prepared statements separate
+this approach might lead to complex to maintain SQL queries. The reason is simple, the actual
+SQL query is not clearly separated from the input parameters. Prepared statements separate
 these two concepts by requiring the developer to add **placeholders** to the SQL query (prepare) which
 are then replaced by their actual values in a second step (execute).
 
@@ -94,7 +94,7 @@ are then replaced by their actual values in a second step (execute).
 Placeholders in prepared statements are either simple positional question marks (?) or named labels starting with
 a double-colon (:name1). You cannot mix the positional and the named approach. The approach
 using question marks is called positional, because the values are bound in order from left to right
-to any question mark found in the previously prepared sql query. That is why you specify the
+to any question mark found in the previously prepared SQL query. That is why you specify the
 position of the variable to bind into the ``bindValue()`` method:
 
 .. code-block:: php
@@ -124,7 +124,7 @@ The following section describes the API of Doctrine DBAL with regard to prepared
 
 .. note::
 
-    The support for positional and named prepared statements varies between the different
+    Support for positional and named prepared statements varies between the different
     database extensions. PDO implements its own client side parser so that both approaches
     are feasible for all PDO drivers. OCI8/Oracle only supports named parameters, but
     Doctrine implements a client side parser to allow positional parameters also.
@@ -137,13 +137,13 @@ use prepared statements:
 
 -   ``prepare($sql)`` - Create a prepared statement of the type ``Doctrine\DBAL\Statement``.
     Using this method is preferred if you want to re-use the statement to execute several
-    queries with the same sql statement only with different parameters.
+    queries with the same SQL statement only with different parameters.
 -   ``executeQuery($sql, $params, $types)`` - Create a prepared statement for the passed
-    sql query, bind the given params with their binding types and execute the query.
+    SQL query, bind the given params with their binding types and execute the query.
     This method returns the executed prepared statement for iteration and is useful
     for SELECT statements.
 -   ``executeUpdate($sql, $params, $types)`` - Create a prepared statement for the passed
-    sql query, bind the given params with their binding types and execute the query.
+    SQL query, bind the given params with their binding types and execute the query.
     This method returns the number of affected rows by the executed query and is useful
     for UPDATE, DELETE and INSERT statements.
 
@@ -173,7 +173,7 @@ If you find it tedious to write all the prepared statement code you can alternat
 the ``Doctrine\DBAL\Connection#executeQuery()`` and ``Doctrine\DBAL\Connection#executeUpdate()``
 methods. See the API section below on details how to use them.
 
-Additionally there are lots of convenience methods for data-retrieval and mainpulation
+Additionally there are lots of convenience methods for data-retrieval and manipulation
 on the Connection, which are all described in the API section below.
 
 Binding Types
@@ -191,7 +191,7 @@ any of the parameter binding methods but a string, Doctrine DBAL will
 ask the type abstraction layer to convert the passed value from
 its PHP to a database representation. This way you can pass ``\DateTime``
 instances to a prepared statement and have Doctrine convert them 
-to the apropriate vendors database format:
+to the appropriate vendors database format:
 
 .. code-block:: php
 
@@ -261,9 +261,9 @@ the SQL and flattens the specified values into the set of parameters. Consider o
         array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY)
     );
 
-The sql statement passed to ``Connection#executeQuery`` is not the one actually passed to the
+The SQL statement passed to ``Connection#executeQuery`` is not the one actually passed to the
 database. It is internally rewritten to look like the following explicit code that could
-be specified aswell:
+be specified as well:
 
 .. code-block:: php
 
@@ -293,7 +293,7 @@ them.
 prepare()
 ~~~~~~~~~
 
-Prepare a given sql statement and return the
+Prepare a given SQL statement and return the
 ``\Doctrine\DBAL\Driver\Statement`` instance:
 
 .. code-block:: php
@@ -315,7 +315,7 @@ Prepare a given sql statement and return the
 executeUpdate()
 ~~~~~~~~~~~~~~~
 
-Executes a prepared statement with the given sql and parameters and
+Executes a prepared statement with the given SQL and parameters and
 returns the affected rows count:
 
 .. code-block:: php
@@ -332,7 +332,7 @@ parameters and expected database values. See the
 executeQuery()
 ~~~~~~~~~~~~~~
 
-Creates a prepared statement for the given sql and passes the
+Creates a prepared statement for the given SQL and passes the
 parameters to the execute method, then returning the statement:
 
 .. code-block:: php
diff --git a/en/reference/introduction.rst b/en/reference/introduction.rst
@@ -2,7 +2,7 @@ Introduction
 ============
 
 The Doctrine database abstraction & access layer (DBAL) offers a
-leightweight and thin runtime layer around a PDO-like API and a lot
+lightweight and thin runtime layer around a PDO-like API and a lot
 of additional, horizontal features like database schema
 introspection and manipulation through an OO API.
 
diff --git a/en/reference/portability.rst b/en/reference/portability.rst
@@ -69,7 +69,7 @@ Database Platform
 -----------------
 
 Using the database platform you can generate bits of SQL for you, specifically
-in the area of sql functions to achieve portability. You should have a look
+in the area of SQL functions to achieve portability. You should have a look
 at all the different methods that the platforms allow you to access.
 
 Keyword Lists
diff --git a/en/reference/schema-manager.rst b/en/reference/schema-manager.rst
@@ -212,15 +212,15 @@ table:
     $toSchema->dropTable('user');
 
 Now we can compare the two schema instances in order to calculate
-the differences between them and return the sql required to make
+the differences between them and return the SQL required to make
 the changes on the database:
 
 .. code-block:: php
 
     <?php
     $sql = $fromSchema->getMigrateToSql($toSchema, $conn->getDatabasePlatform());
 
-The ``$sql`` array should give you a sql query to drop the user
+The ``$sql`` array should give you a SQL query to drop the user
 table:
 
 .. code-block:: php
diff --git a/en/reference/schema-representation.rst b/en/reference/schema-representation.rst
@@ -40,7 +40,7 @@ example shows:
 
 Now if you want to compare this schema with another schema, you can
 use the ``Comparator`` class to get instances of ``SchemaDiff``,
-``TableDiff`` and ``ColumnDiff``, aswell as information about other
+``TableDiff`` and ``ColumnDiff``, as well as information about other
 foreign key, sequence and index changes.
 
 .. code-block:: php
diff --git a/en/reference/transactions.rst b/en/reference/transactions.rst
@@ -36,7 +36,7 @@ is functionally equivalent to the previous one:
 The ``Doctrine\DBAL\Connection`` also has methods to control the
 transaction isolation level as supported by the underlying
 database. ``Connection#setTransactionIsolation($level)`` and
-Connection#getTransactionIsolation() can be used for that purpose.
+``Connection#getTransactionIsolation()`` can be used for that purpose.
 The possible isolation levels are represented by the following
 constants:
 
@@ -60,9 +60,9 @@ transactions, or rather propagating transaction control up the call
 stack. For that purpose, the ``Connection`` class keeps an internal
 counter that represents the nesting level and is
 increased/decreased as ``beginTransaction()``, ``commit()`` and
-``rollback()`` are invoked. ``beginTransaction()`` increases the
+ ``rollback()`` are invoked. ``beginTransaction()`` increases the
 nesting level whilst
-``commit()`` and``rollback()``decrease the nesting level. The nesting level starts at 0. Whenever the nesting level transitions from 0 to 1,``beginTransaction()``is invoked on the underlying driver connection and whenever the nesting level transitions from 1 to 0,``commit()``or``rollback()``is invoked on the underlying driver, depending on whether the transition was caused by``Connection#commit()``or``Connection#rollback()\`.
+ ``commit()`` and ``rollback()`` decrease the nesting level. The nesting level starts at 0. Whenever the nesting level transitions from 0 to 1, ``beginTransaction()`` is invoked on the underlying driver connection and whenever the nesting level transitions from 1 to 0, ``commit()`` or ``rollback()`` is invoked on the underlying driver, depending on whether the transition was caused by ``Connection#commit()`` or ``Connection#rollback()``.
 
 What this means is that transaction control is basically passed to
 code higher up in the call stack and the inner transaction block is
@@ -127,7 +127,7 @@ wider scope and the control is handed to the outer scope.
 .. note::
 
     The transaction nesting described here is a debated
-    feature that has it's critics. Form your own opinion. We recommend
+    feature that has its critics. Form your own opinion. We recommend
     avoiding nesting transaction blocks when possible, and most of the
     time, it is possible. Transaction control should mostly be left to
     a service layer and not be handled in data access objects or
@@ -138,7 +138,7 @@ wider scope and the control is handed to the outer scope.
     Directly invoking ``PDO#beginTransaction()``,
     ``PDO#commit()`` or ``PDO#rollback()`` or the corresponding methods
     on the particular ``Doctrine\DBAL\Driver\Connection`` instance in
-    use bybasses the transparent transaction nesting that is provided
+    use bypasses the transparent transaction nesting that is provided
     by ``Doctrine\DBAL\Connection`` and can therefore corrupt the
     nesting level, causing errors with broken transaction boundaries
     that may be hard to debug.
diff --git a/en/reference/types.rst b/en/reference/types.rst
@@ -5,11 +5,11 @@ Besides abstraction of SQL one needs a translation between database
 and PHP data-types to implement database independent applications.
 Doctrine 2 has a type translation system baked in that supports the
 conversion from and to PHP values from any database platform,
-aswell as platform independent SQL generation for any Doctrine
+as well as platform independent SQL generation for any Doctrine
 Type.
 
 Using the ORM you generally don't need to know about the Type
-system. This is unless you wan't to make use of database vendor
+system. This is unless you want to make use of database vendor
 specific database types not included in Doctrine 2. The following
 PHP Types are abstracted across all the supported database
 vendors:
