[RFC] [VOTE] Implement missing SQLite feature "openBlob" in PDO

  100844
October 9, 2017 22:12 php@bohwaz.net (BohwaZ/PHP)
Kia ora,

After some more discussions, I don't think we have much left to discuss 
on that topic, so…

Voting is now open for 2 weeks on this RFC:
https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo

Vote will end on Wednesday the 25th of October.

Thanks to everyone who contributed to the discussion so far :)
  100863
October 11, 2017 21:03 php@bohwaz.net (BohwaZ/PHP)
Hey,

For people voting against the RFC, could you please explain your vote 
here so that we might understand?

Cheers.


> Kia ora, > > After some more discussions, I don't think we have much left to > discuss on that topic, so… > > Voting is now open for 2 weeks on this RFC: > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo > > Vote will end on Wednesday the 25th of October. > > Thanks to everyone who contributed to the discussion so far :)
  100864
October 11, 2017 23:00 danack@basereality.com (Dan Ackroyd)
On 11 October 2017 at 22:03, BohwaZ/PHP <php@bohwaz.net> wrote:
> Hey, > > For people voting against the RFC, could you please explain your vote here > so that we might understand? > > Cheers.
I think people were reasonably clear during the discussion. Having certain methods only available on an object depending on how it was initialized is just not a good idea. Danack wrote:
> This might be a mistake in how it was implemented originally. Looking > back it seems that it was implemented before we had the RFC > process....and is exactly the type of 'sub-optimal' implementation the > RFC process is meant to prevent. > > ...rather thank just hack in new features building on sub-optimal > ways of doing things, I think it would be better to create a plan to > clean up the way that connection specific methods are available, with > something along the lines of that which I mentioned above.
Regardless of how the vote for this RFC goes, it would be appropriate to have an RFC to clean up how PDO makes connection specific methods available. If the current RFC fails, I would guess that people would be happier adding the connection specific methods in a less magic way. cheers Dan
  100865
October 11, 2017 23:11 php@bohwaz.net (BohwaZ/PHP)
Le 12/10/2017 12:00, Dan Ackroyd a écrit :
> On 11 October 2017 at 22:03, BohwaZ/PHP <php@bohwaz.net> wrote: >> Hey, >> >> For people voting against the RFC, could you please explain your vote >> here >> so that we might understand? >> >> Cheers. > > I think people were reasonably clear during the discussion. > > Having certain methods only available on an object depending on how it > was initialized is just not a good idea.
As far as I know, no one volunteered to rewrite PDO to change that? I don't really understand that logic. Yeah the existing behaviour is not optimal. But there is no other solution right now. Should we also stop adding any feature to PHP because most PHP functions are named incoherently and we need to wait until all of them are renamed correctly? Hopefully not :) It might be years (or never) before that PDO behaviour is changed. In the meantime PHP will just be missing features that could have been provided, this sounds strange to me.
  100866
October 12, 2017 08:23 lester@lsces.co.uk (Lester Caine)
On 12/10/17 00:11, BohwaZ/PHP wrote:
>> I think people were reasonably clear during the discussion. >> >> Having certain methods only available on an object depending on how it >> was initialized is just not a good idea. > > As far as I know, no one volunteered to rewrite PDO to change that? > > I don't really understand that logic. Yeah the existing behaviour is not > optimal. But there is no other solution right now. > > Should we also stop adding any feature to PHP because most PHP functions > are named incoherently and we need to wait until all of them are renamed > correctly? Hopefully not :) > > It might be years (or never) before that PDO behaviour is changed. In > the meantime PHP will just be missing features that could have been > provided, this sounds strange to me.
The 'other solution' right now is to ensure that the generic drivers for each database API do the right thing, and if you must use generic features then use those drivers. PDO SHOULD only provide the lowest common denominator of data abstraction that works CLEANLY independent of the driver selected. That has already been messed up by some of the 'extras' added to individual drivers and it is about time the ground rules were clearly defined and enforced. That nobody has stepped up to finish the parts of PDO that were put on the back burner when it was prematurely pushed into the core build is perhaps a further indication that it was not the right base from the start? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  100871
October 12, 2017 12:06 danack@basereality.com (Dan Ackroyd)
On 12 October 2017 at 00:11, BohwaZ/PHP <php@bohwaz.net> wrote:

> I don't really understand that logic. Yeah the existing behaviour is not > optimal. But there is no other solution right now.
"First, do no harm", "given an existing problem, it may be better not to do something, or even to do nothing, than to risk causing more harm than good." If we add more magic methods to PDO, that are only present when the connection was made to an SQLite DB, then there will be more mess to cleanup, and more people are likely to complain about BC breaks, if/when we refactor the features to not have shitty magic behaviour. People have suggested changing the RFC process to require 2/3 approval for all RFCs. This RFC is a prime example of why that might be needed. We shouldn't be approving changes that are just barely good enough to be included. Changes should be clearly the right choice, to be included.
> It might be years (or never) before that PDO behaviour is changed. In the meantime PHP will just be missing features that could have been provided, this sounds strange to me.
openBlob has been available in the ext/sqlite3 extension for nine years, apparently. If it hasn't been present in PDO for all that time, and yet somehow people have still managed to be able to use PHP, then it doesn't exactly demonstrate that this is a feature that urgently needs to be added, no matter how much extra mess it leaves.
> Should we also stop adding any feature to PHP because most > PHP functions are named incoherently and we need to wait until > all of them are renamed correctly? Hopefully not :)
You have a habit of taking people's opinions, and then trying to take them to illogical conclusions, in order to try to win a discussion. This seems to put you in the position of not even trying to understand the other persons point of view, which is not helpful to you, if you're trying to persuade people. It also makes me not want to interact with you, as you're being deliberately obtuse. cheers Dan Ack
  100879
October 12, 2017 15:48 php@beccati.com (Matteo Beccati)
Hi Dan,

On 12/10/2017 14:06, Dan Ackroyd wrote:
> If we add more magic methods to PDO, that are only present when the > connection was made to an SQLite DB, then there will be more mess to > cleanup, and more people are likely to complain about BC breaks, > if/when we refactor the features to not have shitty magic behaviour.
Since no one is planning to do such refactoring anytime soon, I see no reason to block any attempt to add driver-specific methods (i.e. features that only belong to a specific driver) until further notice. Whoever chooses to use them knows already their code is not portable to other drivers anyway. I have added a few PDO::pgsql* ones myself and feel no shame ;)
> People have suggested changing the RFC process to require 2/3 approval > for all RFCs. This RFC is a prime example of why that might be needed. > We shouldn't be approving changes that are just barely good enough to > be included. Changes should be clearly the right choice, to be > included.
I agree with the 2/3 boundary, but this specific RFC follows PDO's current standards. The fact that they are suboptimal to me is out of scope. Sill, I hope that proper LOB field type support lands in PDO_sqlite as well soon after. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/
  100906
October 19, 2017 12:46 danack@basereality.com (Dan Ackroyd)
On 12 October 2017 at 16:48, Matteo Beccati <php@beccati.com> wrote:

> Since no one is planning to do such refactoring anytime soon,
Actually, I am planning to.
> I see no > reason to block any attempt to add driver-specific methods
I think I would be more likely to believe that argument, if we were weeks away from the 7.3 release, rather than a year away. There's plenty of reason to hold off on a, in my opinion, substandard implementation when there is a year to get a better implementation. cheers Dan Ack
  100889
October 13, 2017 07:57 me@kelunik.com (Niklas Keller)
Hey,

please add the voting dates below / above the vote on the RFC's page,
thanks!

Regards, Niklas

2017-10-10 0:12 GMT+02:00 BohwaZ/PHP <php@bohwaz.net>:

> Kia ora, > > After some more discussions, I don't think we have much left to discuss on > that topic, so… > > Voting is now open for 2 weeks on this RFC: > https://wiki.php.net/rfc/implement_sqlite_openblob_in_pdo > > Vote will end on Wednesday the 25th of October. > > Thanks to everyone who contributed to the discussion so far :) > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >