Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Date: Fri, 22 Jan 2016 15:35:54 +0200
Message-ID: <CAMRr2dzLs2H8zho4AhjUuSMOyG9ZnQVyMDCx9o168M+hs1WAdg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=089e011763118b65740529ec4dc4
Subject: Re: PDO Close Connection
From: gabriel.zerbib@gmail.com (Gabriel Zerbib)

--089e011763118b65740529ec4dc4
Content-Type: text/plain; charset=UTF-8

>
>
> ---------- Forwarded message ----------
> From: Rowan Collins <rowan.collins@gmail.com>
> To: internals@lists.php.net
> Cc:
> Date: Thu, 21 Jan 2016 19:18:51 +0000
>
>
> 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');
>
>

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');

In other words, the developer who explicitly closes a resource, knows why
he is doing it, supposedly.


> The object needs to track the fact that it is in a closed state, and do
> something - maybe throw a ConnectionAlreadyClosedException?
>

I think that the PHP developers are quite familiar with this when it comes
to files or sockets, and people like to use fclose when they think it's
needed.

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.



> So that means the close() method needs to be accompanied by a reopen()
> method, which means saving the DSN and credentials
>


This use case remains true, if there are other references to $fp elsewhere
in the code. The underlying resource is simply freed, and the object did
not keep track of the path or opening mode, etc.



>
> 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.
>

I think you are perfectly right when it comes to design patterns and good
practices. But alas not every PHP user will or can implement them in this
way.

Even when doing things properly, e.g. using a stable and popular ORM like
Doctrine, I could end up writing:

  $pdo = $entityManager->getConnection()->getWrappedConnection();

and then even if Doctrine offered a way to nullify its internal PDO
reference, I ruined it.


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 :)

Of course a PDO closeConnection method is not the hottest emergency, but
all I'm saying is that I could use it... !


Thanks,
Regards,

Gabriel

--089e011763118b65740529ec4dc4--