Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Various minor improvements such as typo and grammar fixes etc. #3

Merged
merged 24 commits into from

2 participants

@bantu

No description provided.

@beberlei beberlei merged commit f61d417 into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Oct 26, 2011
  1. @bantu
  2. @bantu
  3. @bantu
  4. @bantu
  5. @bantu
  6. @bantu
  7. @bantu
  8. @bantu
  9. @bantu

    No such word as 'aswell'.

    bantu authored
  10. @bantu

    Remove unwanted 'and'.

    bantu authored
  11. @bantu
  12. @bantu

    Also spell 'MySQL' consistently.

    bantu authored
  13. @bantu
Commits on Oct 27, 2011
  1. @bantu
  2. @bantu
  3. @bantu
  4. @bantu
  5. @bantu
  6. @bantu
  7. @bantu
  8. @bantu

    Fix various displays of code.

    bantu authored
  9. @bantu
  10. @bantu

    Typo: bybasses => bypasses

    bantu authored
  11. @bantu

    Typo: wan't => want

    bantu authored
This page is out of date. Refresh to see the latest.
View
2  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
View
6 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>`_.
View
46 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
View
2  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.
View
2  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
View
4 en/reference/schema-manager.rst
@@ -212,7 +212,7 @@ 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
@@ -220,7 +220,7 @@ the changes on the database:
<?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
View
2  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
View
10 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.
View
4 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:
Something went wrong with that request. Please try again.