[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 > >
  100985
October 30, 2017 03:14 danack@basereality.com (Dan Ackroyd)
The vote for this should have ended......3 days ago.

At which point I believe the vote was actually passing.

cheers
Dan

On 9 October 2017 at 23:12, BohwaZ/PHP <php@bohwaz.net> wrote:
> 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 >
  100998
October 30, 2017 20:11 rowan.collins@gmail.com (Rowan Collins)
On 30/10/2017 03:14, Dan Ackroyd wrote:
> The vote for this should have ended......3 days ago. > > At which point I believe the vote was actually passing.
Hm, that's awkward! For the record: - voting was announced on the evening of the 9th "for two weeks" which would imply the evening of the 23rd - however, the e-mail also said "Vote will end on Wednesday the 25th of October. " - the wiki page states "Vote closing on Oct 27, 2017." - https://php-rfc-watch.beberlei.de/ lists "daverandom" voting No at 2017-10-28T07:28:00+0000 (*mutters something about relative date display being uselessly vague*) It's possible that daverandom was several hours west of Greenwich at the time (e.g. in North America), where it was still late on October 27th. So taking the latest of the three published closing dates, and applying the most generous time zone, it's possible that all the votes were valid. It's certainly clear that no *new* votes should be counted. The last vote before that according to the rfc-watch tool was "salathe" on the 21st, so if daverandom's vote is *not* valid, the RFC passes 7:6; however, if daverandom's vote *is* valid, we have 7:7, and the RFC is declined. In my opinion, the very fact that it was this close suggests that there is not consensus in favour of the change, and therefore it would be reasonable to err on the side of caution, and not adopt the change. Regards, -- Rowan Collins [IMSoP]
  101003
October 31, 2017 21:05 adambaratz@php.net (Adam Baratz)
> > It's possible that daverandom was several hours west of Greenwich at the > time (e.g. in North America), where it was still late on October 27th. So > taking the latest of the three published closing dates, and applying the > most generous time zone, it's possible that all the votes were valid.
https://github.com/DaveRandom At least according to his GitHub profile, he's in the UK.
> In my opinion, the very fact that it was this close suggests that there is > not consensus in favour of the change, and therefore it would be reasonable > to err on the side of caution, and not adopt the change. >
My take would be that "rules are rules." The RFC was defined as 50%+1. Thanks, Adam
  101013
November 1, 2017 10:00 derick@php.net (Derick Rethans)
On Mon, 30 Oct 2017, Rowan Collins wrote:

> On 30/10/2017 03:14, Dan Ackroyd wrote: > > The vote for this should have ended......3 days ago. > >=20 > > At which point I believe the vote was actually passing. >=20 >=20 > Hm, that's awkward! >=20 > For the record: >=20 > - voting was announced on the evening of the 9th "for two weeks" which wo= uld
> imply the evening of the 23rd > - however, the e-mail also said "Vote will end on Wednesday the 25th of > October. " > - the wiki page states "Vote closing on Oct 27, 2017." > - https://php-rfc-watch.beberlei.de/ lists "daverandom" voting No at > 2017-10-28T07:28:00+0000 (*mutters something about relative date display = being
> uselessly vague*) >=20 > It's possible that daverandom was several hours west of Greenwich at the = time
> (e.g. in North America), where it was still late on October 27th. So taki= ng
> the latest of the three published closing dates, and applying the most > generous time zone, it's possible that all the votes were valid. >=20 > It's certainly clear that no *new* votes should be counted. >=20 > The last vote before that according to the rfc-watch tool was "salathe" o= n the
> 21st, so if daverandom's vote is *not* valid, the RFC passes 7:6; however= , if
> daverandom's vote *is* valid, we have 7:7, and the RFC is declined.
7:6 is technically not "50%"+1. 50% of 13 is 6=C2=BD, and 7 is not higher= =20 than 6=C2=BD + 1. :-) cheers, Derick --=20 https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug
  101020
November 1, 2017 21:24 php@bohwaz.net (BohwaZ)
On Mon, 30 Oct 2017 20:11:18 +0000 / Rowan Collins
collins@gmail.com> said :

> On 30/10/2017 03:14, Dan Ackroyd wrote: > > The vote for this should have ended......3 days ago. > > > > At which point I believe the vote was actually passing. > > > Hm, that's awkward! > > For the record: > > - voting was announced on the evening of the 9th "for two weeks" > which would imply the evening of the 23rd > - however, the e-mail also said "Vote will end on Wednesday the 25th > of October. "
Don't know where that 9th is from? I posted my email around 11 am on Tusday October 10th, so +2 weeks is Tuesday October 24th, but I thought it would close at midnight, so on the 25th :)
> - the wiki page states "Vote closing on Oct 27, 2017."
My bad there, sorry, I counted two weeks from when someone told me to put the date on the wiki (which I forgot to do).
> - https://php-rfc-watch.beberlei.de/ lists "daverandom" voting No at > 2017-10-28T07:28:00+0000 (*mutters something about relative date > display being uselessly vague*) > > It's possible that daverandom was several hours west of Greenwich at > the time (e.g. in North America), where it was still late on October > 27th. So taking the latest of the three published closing dates, and > applying the most generous time zone, it's possible that all the > votes were valid.
Ah yeah didn't thought of that, but I'm in NZ, so the dates I talked about were UTC+13.
> In my opinion, the very fact that it was this close suggests that > there is not consensus in favour of the change, and therefore it > would be reasonable to err on the side of caution, and not adopt the > change.
Agreed.
  101023
November 1, 2017 22:50 rowan.collins@gmail.com (Rowan Collins)
Just for the record, this question:

> Don't know where that 9th is from? I posted my email around 11 am on > Tusday October 10th
Is answered by this sentence:
> Ah yeah didn't thought of that, but I'm in NZ, so the dates I > talked about were UTC+13.
I'm in Europe/London time, so 11am for you was 11pm the night before for me. For anyone reading in North America, it was still the previous afternoon. Man I hate time zones! ;) Regards, -- Rowan Collins [IMSoP]
  101017
November 1, 2017 17:47 php@bohwaz.net (BohwaZ)
Sorry I thought the vote would automatically close, but apparently it
doesn't work like that. I was away from the internet so couldn't edit
the wiki page.

I can't find the place where we can see the voting history? Last time I
checked the page last week it was 6 to 5 or something like that.

On Mon, 30 Oct 2017 03:14:03 +0000 / Dan Ackroyd
<danack@basereality.com> said :

> The vote for this should have ended......3 days ago. > > At which point I believe the vote was actually passing. > > cheers > Dan > > On 9 October 2017 at 23:12, BohwaZ/PHP <php@bohwaz.net> wrote: > > 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 > > >
  101018
November 1, 2017 19:08 rowan.collins@gmail.com (Rowan Collins)
On 1 November 2017 17:47:55 GMT+00:00, BohwaZ <php@bohwaz.net> wrote:
>I can't find the place where we can see the voting history? Last time I >checked the page last week it was 6 to 5 or something like that.
See my email in this thread from a couple of days ago. Last vote was a yes, but probably too late, leaving 6:6, which means no consensus to merge this implementation. Hopefully we can get some momentum behind a more general API that allows this feature in a way that will be more positively received. Regards, -- Rowan Collins [IMSoP]
  101019
November 1, 2017 19:51 php@bohwaz.net (BohwaZ)
On Wed, 01 Nov 2017 19:08:56 +0000 / Rowan Collins
collins@gmail.com> said :

> On 1 November 2017 17:47:55 GMT+00:00, BohwaZ <php@bohwaz.net> wrote: > >I can't find the place where we can see the voting history? Last > >time I checked the page last week it was 6 to 5 or something like > >that. > > See my email in this thread from a couple of days ago. Last vote was > a yes, but probably too late, leaving 6:6, which means no consensus > to merge this implementation. > > Hopefully we can get some momentum behind a more general API that > allows this feature in a way that will be more positively received.
OK, thanks. I marked the RFC as rejected. I'll be leaving this list now as this marks the end of my contributions to PHP, as my free time is very limited and I want to spend it on useful activities. So good luck to the next person who will rewrite that part of PDO, if that happens. Thanks everyone :)