Gabriel Zerbib wrote on 21/01/2016 14:32:
Hi, list!
This is my first email to this mailing list, so please pardon me for misuse
of the traditions you may have here (formatting, phrasing, etc.).
Welcome! :)
Maybe this has been discussed in depth earlier, but: I want to ask if there
is an explicit reason for not giving a "close" instance method in the PDO
class.
I think the main problem with a close method on something that
represents a resource like a PDO connection object is how the object
should behave *after* it has been closed. That is, what should the
following code do?
$pdo = new PDO($dsn);
$pdo->closeConnection();
$pdo->query('Select 1 as test');
The object needs to track the fact that it is in a closed state, and do
something - maybe throw a ConnectionAlreadyClosedException? But then
what should the calling code do about that? If you have many objects
with reference to that PDO object, then any one of them could "close"
it, and any one could then try to execute a query. If you're not
careful, your closeConnection() method could become a
killScriptNextTimeAQueryIsAttempted() method.
If what you are actually doing is putting the connection to sleep, to be
"woken up" later, you need *all* the references to the object to have
the ability to "wake it up", because if you just create a new
connection, you've somehow got to propagate it to all the same places
you'd have to unset() in the current implementation. So that means the
close() method needs to be accompanied by a reopen() method, which means
saving the DSN and credentials, and any initialisation calls you want to
make at the beginning of the connection (setting encoding, etc)...
In an application made of dependency injection, closures and many levels of
function calls split over many files, it is virtually impossible to keep
reference counting mentally, and you mostly end up never knowing what other
component of the application still retains a reference to the PDO object.
One solution to this is to create a wrapper around PDO, which is the
only thing allowed to have a direct reference to the PDO object itself.
To this object, you can add a close() method to your wrapper, and maybe
isOpen(). If you save the DSN as well as the connection object, you can
then go further and have reopen(), openOnNextQuery() (lazy-loading), or
have your implementation of query() silently ensure that a connection is
open. You could have a hook that fires on connection / disconnection to
notify other objects, a list of SQL calls to run on connection, etc. etc.
That's not to say that a simple implementation of just
close-and-fire-exception would be a horrible idea in PDO, but having one
object which represents an open connection, and a separate one which
represents a *potential* connection (maybe open, maybe closed, maybe
not-open-yet) is a useful abstraction, and doesn't need anything in PDO
itself.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
