Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90804
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: internals@lists.php.net
References: <CAMRr2dzb+04nBaVDjnkTPX-xYn=7WT4mmUrKO2MaxO=x=vpxpw@mail.gmail.com>
Message-ID: <56A12F1B.9080708@gmail.com>
Date: Thu, 21 Jan 2016 19:18:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAMRr2dzb+04nBaVDjnkTPX-xYn=7WT4mmUrKO2MaxO=x=vpxpw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PDO Close Connection
From: rowan.collins@gmail.com (Rowan Collins)

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]