Skip to content

D
doctrine-dbal
Commit 399ab63d authored by Marco Pivetta's avatar Marco Pivetta Committed by GitHub
Browse files
Options

Merge pull request #2793 from afoeder/patch-1 

[TASK] Fix articles of words sounding with a consonant
parents 3a6110f2 ee5166ba
Show whitespace changes
Inline Side-by-side
Showing with 5 additions and 5 deletions
docs/en/reference/types.rst
View file @ 399ab63d
......@@ -378,7 +378,7 @@ using deserialization or ``null`` if no data is present.
This type will always be mapped to the database vendor's ``text`` type
internally as there is no way of storing a PHP array representation
natively in the database.
Furthermore this type requires a SQL column comment hint so that it can be
Furthermore this type requires an SQL column comment hint so that it can be
reverse engineered from the database. Doctrine cannot map back this type
properly on vendors not supporting column comments and will fall back to
``text`` type instead.
......@@ -398,7 +398,7 @@ using comma delimited ``explode()`` or ``null`` if no data is present.
This type will always be mapped to the database vendor's ``text`` type
internally as there is no way of storing a PHP array representation
natively in the database.
Furthermore this type requires a SQL column comment hint so that it can be
Furthermore this type requires an SQL column comment hint so that it can be
reverse engineered from the database. Doctrine cannot map back this type
properly on vendors not supporting column comments and will fall back to
``text`` type instead.
......@@ -426,7 +426,7 @@ Values retrieved from the database are always converted to PHP's ``array`` or
Some vendors have a native JSON type and Doctrine will use it if possible
and otherwise silently fall back to the vendor's ``text`` type to ensure
the most efficient storage requirements.
If the vendor does not have a native JSON type, this type requires a SQL
If the vendor does not have a native JSON type, this type requires an SQL
column comment hint so that it can be reverse engineered from the database.
Doctrine cannot map back this type properly on vendors not supporting column
comments and will fall back to ``text`` type instead.
......@@ -449,7 +449,7 @@ using PHP's ``json_decode()`` function.
Some vendors have a native JSON type and Doctrine will use it if possible
and otherwise silently fall back to the vendor's ``text`` type to ensure
the most efficient storage requirements.
If the vendor does not have a native JSON type, this type requires a SQL
If the vendor does not have a native JSON type, this type requires an SQL
column comment hint so that it can be reverse engineered from the database.
Doctrine cannot map back this type properly on vendors not supporting column
comments and will fall back to ``text`` type instead.
......@@ -474,7 +474,7 @@ using deserialization or ``null`` if no data is present.
This type will always be mapped to the database vendor's ``text`` type
internally as there is no way of storing a PHP object representation
natively in the database.
Furthermore this type requires a SQL column comment hint so that it can be
Furthermore this type requires an SQL column comment hint so that it can be
reverse engineered from the database. Doctrine cannot map back this type
properly on vendors not supporting column comments and will fall back to
``text`` type instead.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment