Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90840
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
To: internals@lists.php.net
References: <CAMRr2dzLs2H8zho4AhjUuSMOyG9ZnQVyMDCx9o168M+hs1WAdg@mail.gmail.com>
Message-ID: <56A2804F.4010006@gmail.com>
Date: Fri, 22 Jan 2016 19:17:35 +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: <CAMRr2dzLs2H8zho4AhjUuSMOyG9ZnQVyMDCx9o168M+hs1WAdg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PDO Close Connection
From: rowan.collins@gmail.com (Rowan Collins)

Gabriel Zerbib wrote on 22/01/2016 13:35:

> I hear your point, but I think that the problem is mostly similar to the
> following piece:
>
>    $fp = fopen('filename', 'w');
>    fclose($fp);
>    fwrite($fp, 'data');

Sure, but does that mean that PDO should gain a close function, or that 
the file functions would be better if they didn't have it? That is 
effectively the question we're discussing.


> Suppose you opened a file for writing, and then you're done with it (so
> that other processes can have it), but your script must then enter a
> time-consuming loop, or sleep, or wait blockingly for another resource. You
> don't want to lock stalled the initial file when you know you're finished
> with it, therefore you call fclose. And you already know, that, should you
> need it again, you would call fopen again.

If you have a single reference to the file pointer in your code, then 
this is true, and is equivalent to the current unset($pdo) case. When 
you need it again, you call new PDO() again.

If you, as you described in your original post, "end up never knowing 
what other component of the application still retains a reference", then 
running fclose($fh) seems very dangerous indeed - none of those places 
know that next time they read from the file handle, they need to reopen 
the file to avoid an error; indeed, they probably don't know *how* to 
reopen the file. Most will just assume that, because they were given a 
file handle, rather than creating their own, that file handle is and 
will remain valid.


> Besides, expecting from PHP users that they write a Facade/Singleton
> pattern to wrap a core class and proxy all its publics, seems high
> standards :)

It doesn't seem that complex to me. I just hacked together a version 
(untested, and unoptimised) in 22 lines of code which implements the 
"close and then error forever" pattern: 
https://gist.github.com/IMSoP/bb0aecf214071a5b59cb This would be really 
easy to add to core, but also not that useful - do you really want every 
class which has a reference to that object to generate a stream of 
exceptions when they try to query?

To actually make it useful, you need to have something you can do about 
it, like an openConnection() method. Here's a more complex wrapper, 
still only 30 lines of code, which implements a lazy connection (connect 
on first use, reconnect on first use after closing): 
https://gist.github.com/IMSoP/a8e329e81eacd22a66c1

But this is probably missing features, which different people might want 
to do in different ways, e.g. if you call setAttribute(), should the 
option stay set after a close() / open() or be reverted (I can imagine 
use cases for both ways around)? Should the connection automatically 
reopen itself like this, or should it throw an exception and expect the 
caller to call open()? Should the connection be opened on construct, or 
on first use? Should there be an accessor for isOpen(), or an 
ensureOpen()? And if this class replaced PDO, would we be storing 
credentials in memory which are normally used once at connection time 
and then discarded?

As ever, the devil is in the detail. PDO in general operates at quite a 
low-level, rather than being an opinionated implementation. The joy of 
the PHP ecosystem right now is that there are tons of nice libraries out 
there, and you don't have to wait for a new PHP version to get a bugfix 
or feature, just "composer update".

Regards,
-- 
Rowan Collins
[IMSoP]