RetailCRM-Mirror/doctrine2
1
0
Fork 0
mirror of synced 2025-02-09 00:39:25 +03:00
Code Issues Projects Releases Wiki Activity

Promote nullable types from PHP 7.1

Browse Source 
Also don't show type hinting in a bad light with sentences such as "If you insist on type-hinting"
This commit is contained in:
Adrien Crivelli 2017-09-21 17:29:54 +09:00 committed by GitHub
parent 0c4f9a8866
commit d995203ee1
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
docs/en/reference/working-with-associations.rst
View File

@ -238,14 +238,19 @@ the database permanently.
Notice how both sides of the bidirectional association are always
updated. Unidirectional associations are consequently simpler to
handle. Also note that if you use type-hinting in your methods, i.e.
``setAddress(Address $address)``, PHP will only allow null
values if ``null`` is set as default value. Otherwise
setAddress(null) will fail for removing the association. If you
insist on type-hinting a typical way to deal with this is to
provide a special method, like ``removeAddress()``. This can also
provide better encapsulation as it hides the internal meaning of
not having an address.
handle.
Also note that if you use type-hinting in your methods, i.e.
``setAddress(Address $address)``, you will have to specifically
allow null values, otherwise ``setAddress(null)`` will fail to
remove the association. Starting from PHP 7.1 you should use
nullable types by prefixing the type with a ``?``,
``setAddress(?Address $address)``. Older PHP versions will only
allow null values if ``null`` is set as default value,
``setAddress(Address $address = null)``. Yet another way to deal
with this is to provide a special method, like ``removeAddress()``.
This can also provide better encapsulation as it hides the internal
meaning of not having an address.
When working with collections, keep in mind that a Collection is
essentially an ordered map (just like a PHP array). That is why the
@ -396,7 +401,7 @@ There are two approaches to handle this problem in your code:
1. Ignore updating the inverse side of bidirectional collections,
BUT never read from them in requests that changed their state. In
the next Request Doctrine hydrates the consistent collection state
the next request Doctrine hydrates the consistent collection state
again.
2. Always keep the bidirectional collections in sync through
association management methods. Reads of the Collections directly