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

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 :)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 11 October 2017 at 22:03, BohwaZ/PHP <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Le 12/10/2017 12:00, Dan Ackroyd a écrit :
> On 11 October 2017 at 22:03, BohwaZ/PHP <[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 12 October 2017 at 00:11, BohwaZ/PHP <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 <[email protected]>:

> 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
>
>

On 12 October 2017 at 16:48, Matteo Beccati <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 <[email protected]> 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
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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
<[email protected]> 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 <[email protected]> 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
> >
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 1 November 2017 17:47:55 GMT+00:00, BohwaZ <[email protected]> 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, 01 Nov 2017 19:08:56 +0000 / Rowan Collins
<[email protected]> said :

> On 1 November 2017 17:47:55 GMT+00:00, BohwaZ <[email protected]> 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 :)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, 30 Oct 2017 20:11:18 +0000 / Rowan Collins
<[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php