Welcome! Log In Create A New Profile

Advanced

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

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

--
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
>
>
Sorry, only registered users may post in this forum.

Click here to login