Re: [PHP-DEV] [Request][Discussion] Introduce interfaces PDOInterfaceand PDOStatementInterface

  100154
August 3, 2017 16:59 newaltgroup@bk.ru (Andrew Nester)
> On Jul 31, 2017, at 6:33 PM, Johannes Schlüter <johannes@schlueters.de> wrote: > > (off-list as this is distracting the discussion) > > On Mo, 2017-07-31 at 18:00 +0300, Andrew Nester wrote: >> >>> On Jul 31, 2017, at 5:54 PM, Johannes Schlüter <johannes@schlueters >>> .de> wrote: >>> >>> On Mo, 2017-07-31 at 14:49 +0300, Andrew Nester wrote: >>>> That’s actually the thing that you can’t use >>>> PDO::ATTR_STATEMENT_CLASS with persistent PDO. >>> The actually question is: Why not? - From a quick glance on the >>> code I see no obvious reason > [...] >> Besides code style/architecture things (which is of course >> questionable) the issue with ATTR_STATEMENT_CLASS is that it simply >> doesn’t work with persistent PDO connect and raises >> "General error: PDO::ATTR_STATEMENT_CLASS cannot be used with >> persistent PDO instances" > > Yes, and my question is "why can't it?" I see no obvious reason in the > code. If we can lift weird restrictions from internals this is always > good ... > > johannes
I am thinking about writing an RFC for this and continue discussion there. Will it be a good idea?
  100160
August 6, 2017 13:30 danack@basereality.com (Dan Ackroyd)
Andrew Nester wrote:
> I am thinking about writing an RFC for this and continue discussion there.. > Will it be a good idea?
You're apparently not very good at listening to suggestions, so I'll be more direct. I think you're wasting people's time until you actually try seeing if PDO can be made to work with userland classes or not. The next step should be you (or anyone else) attempting to make the required changes to PDO to make it work, to discover what changes would be needed to allow using userland classes. If it isn't known what is needed to do to support it working, there is no point raising the RFC. Johannes Schlüter wrote:
> The actually question is: Why not?
My understanding is that some of the internal code that calls userland functions and methods is basically bogus. I had a PR (which I haven't had the energy to get round to sorting out) to make the SPL call userland constructors correctly: https://github.com/php/php-src/pull/1196 My surprise level would be zero, if there were similar issues in PDO instantiating user classes, or other issues like the internal code accessing properties directly without going through method access. On the other hand, it might 'just work'. cheers Dan Ack
  100161
August 6, 2017 15:12 newaltgroup@bk.ru (Andrew Nester)
> 6 авг. 2017 г., в 16:30, Dan Ackroyd <danack@basereality.com> написал(а): > > Andrew Nester wrote: >> I am thinking about writing an RFC for this and continue discussion there.. >> Will it be a good idea? > > You're apparently not very good at listening to suggestions, so I'll > be more direct. > > I think you're wasting people's time until you actually try seeing if > PDO can be made to work with userland classes or not. > > The next step should be you (or anyone else) attempting to make the > required changes to PDO to make it work, to discover what changes > would be needed to allow using userland classes. > > If it isn't known what is needed to do to support it working, there is > no point raising the RFC. > > > Johannes Schlüter wrote: >> The actually question is: Why not? > > My understanding is that some of the internal code that calls userland > functions and methods is basically bogus. > > I had a PR (which I haven't had the energy to get round to sorting > out) to make the SPL call userland constructors correctly: > https://github.com/php/php-src/pull/1196 > > My surprise level would be zero, if there were similar issues in PDO > instantiating user classes, or other issues like the internal code > accessing properties directly without going through method access. > > On the other hand, it might 'just work'. > > cheers > Dan > Ack
Thanks for your feedback, I appreciate this. Yes, I understand what you mean. Fixing using this PDO attribute will solve issue with persistent PDO and will allow to customize PDO in all cases. But what I want to suggest is more straightforward way to customize PDO behaviour and have proper type hints at the same time, because at my opinion using PDO attributes for customization is not very straightforward. I shown you some examples of use cases of these interfaces. As I think example from Doctrine DBAL shows that this might be useful. Let me know if you would like to see some others. I would like to hear some arguments why my proposed solution will not work or what exactly wrong with interfaces proposed and solution in general. Thanks in advance.
February 15, 2018 16:53 aljosha.papsch@vinexus.eu (Aljosha Papsch)
Am 06.08.2017 um 17:12 schrieb Andrew Nester:
> > >> 6 авг. 2017 г., в 16:30, Dan Ackroyd <danack@basereality.com> написал(а): >> >> Andrew Nester wrote: >>> I am thinking about writing an RFC for this and continue discussion there. >>> Will it be a good idea? >> >> You're apparently not very good at listening to suggestions, so I'll >> be more direct. >> >> I think you're wasting people's time until you actually try seeing if >> PDO can be made to work with userland classes or not. >> >> The next step should be you (or anyone else) attempting to make the >> required changes to PDO to make it work, to discover what changes >> would be needed to allow using userland classes. >> >> If it isn't known what is needed to do to support it working, there is >> no point raising the RFC. >> >> >> Johannes Schlüter wrote: >>> The actually question is: Why not? >> >> My understanding is that some of the internal code that calls userland >> functions and methods is basically bogus. >> >> I had a PR (which I haven't had the energy to get round to sorting >> out) to make the SPL call userland constructors correctly: >> https://github.com/php/php-src/pull/1196 >> >> My surprise level would be zero, if there were similar issues in PDO >> instantiating user classes, or other issues like the internal code >> accessing properties directly without going through method access. >> >> On the other hand, it might 'just work'. >> >> cheers >> Dan >> Ack > > Thanks for your feedback, I appreciate this. > > Yes, I understand what you mean. > Fixing using this PDO attribute will solve issue with persistent PDO and will allow to customize PDO in all cases. > > But what I want to suggest is more straightforward way to customize PDO behaviour and have proper type hints at the same time, because at my opinion using PDO attributes for customization is not very straightforward. > > I shown you some examples of use cases of these interfaces. As I think example from Doctrine DBAL shows that this might be useful. Let me know if you would like to see some others. > > I would like to hear some arguments why my proposed solution will not work or what exactly wrong with interfaces proposed and solution in general. > > Thanks in advance. > >
Let me revive this thread. I submitted bug #74957 and therefore I am in favor of the interfaces. My original motivation for the bug report was having a custom implementation which would be able to catch from the original PDO "MySQL server has gone away" and broken pipes, arising from idle connections being reused after a while. This not only happens in mostly idle daemons, but could also happen in this circumstance: 1. two connections are opened: log and work. 2. log connection is used. 3. work connection is used, blocking for several minutes. 4. log connection is used again. Result is broken pipe for the log connection. Now, I'm not too sure if the custom PDO implementation will help for this use case (catching broken pipes), because in one app instance PDO triggers an error and in another instance it causes a shutdown. Same app version, both PHP 7.1. The interfaces would still be a nice addition. They provide a good basis for experimentation. They allow general straight forward customization of PDO, i.e. not having to find out about the arcane and funny looking customization method PDO:: ATTR_STATEMENT_CLASS, which is also restricted to PDOStatement customization. Best regards Aljosha
  101922
February 25, 2018 17:04 danack@basereality.com (Dan Ackroyd)
On 15 February 2018 at 16:53, Aljosha Papsch papsch@vinexus.eu> wrote:
> > Let me revive this thread.
So.......have you looked at doing the suggested next steps? Or possibly offered to pay someone to do it? On 6 August 2017 at 14:30, Dan Ackroyd <danack@basereality.com> wrote:
> > The next step should be you (or anyone else) attempting to make the > required changes to PDO to make it work, to discover what changes > would be needed to allow using userland classes. > > If it isn't known what is needed to do to support it working, there is > no point raising the RFC.
To be clear - this idea sounds like a good one. But it needs someone to do the work, rather than more discussion about. cheers Dan Ack