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 :)
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_pdoVote will end on Wednesday the 25th of October.
Thanks to everyone who contributed to the discussion so far :)
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
Le 12/10/2017 12:00, Dan Ackroyd a écrit :
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.
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
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
Hi Dan,
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/
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
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_pdoVote will end on Wednesday the 25th of October.
Thanks to everyone who contributed to the discussion so far :)
The vote for this should have ended......3 days ago.
At which point I believe the vote was actually passing.
cheers
Dan
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_pdoVote will end on Wednesday the 25th of October.
Thanks to everyone who contributed to the discussion so far :)
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]
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.
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
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.
7:6 is technically not "50%"+1. 50% of 13 is 6½, and 7 is not higher
than 6½ + 1. :-)
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug
On Mon, 30 Oct 2017 20:11:18 +0000 / Rowan Collins
rowan.collins@gmail.com said :
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.
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]
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
DanKia 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_pdoVote will end on Wednesday the 25th of October.
Thanks to everyone who contributed to the discussion so far :)
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]
On Wed, 01 Nov 2017 19:08:56 +0000 / Rowan Collins
rowan.collins@gmail.com said :
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 :)