[RFC] Extended String Types For PDO

7 years ago by Adam Baratz — view source

unread

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542

Please let me know what you think.

Thanks,
Adam

Any thoughts on this one?

7 years ago by Andrea Faulds — view source

unread

Hi Adam,

Adam Baratz wrote:

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542

Please let me know what you think.

Thanks,
Adam

Any thoughts on this one?

It seems like a sensible proposal to me. Two points:

Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the
most appropriate names? For one thing, PARAM_STR_ASCII would seem to
imply such strings can only contain ASCII, but that is not the case.
Likewise, PARAM_STR_UNICODE might be understood as being required for
Unicode use, but that is also not the case. Also, both MySQL and MSSQL
refer to such strings as “national” strings, even if they are Unicode
underneath. Would it be better if the terminology we used matched these
databases', for recognisability's sake? That would also resolve
potential confusion with the constant names, they could be e.g.
PARAM_CHAR, ATTR_NATIONAL_CHAR and PARAM_NATIONAL_CHAR, or something
like that.
How does this interact with different character sets used for the
connection, if at all?

Thanks!

--
Andrea Faulds
https://ajf.me/

7 years ago by Marco Pivetta — view source

unread

Hi Adam

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated
prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542

Please let me know what you think.

Thanks,
Adam

Any thoughts on this one?

DBAL maintainer here: before we introduce even more complexity into the PDO
stuff (which is already a maze), could a set of test cases be written, so
that stuff that is currently impossible to do without this RFC is
clearer/demonstrated?

I'm asking because we didn't get any bug reports about extended string
types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects (remember that PDO for SQLServer is
experimental, if not totally unusable) is shotgun surgery, and just more
complexity to handle.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

7 years ago by Christopher Jones — view source

unread

Hi Adam

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated
prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542

Please let me know what you think.

Thanks,
Adam

Any thoughts on this one?

DBAL maintainer here: before we introduce even more complexity into the PDO
stuff (which is already a maze), could a set of test cases be written, so
that stuff that is currently impossible to do without this RFC is
clearer/demonstrated?

I'm asking because we didn't get any bug reports about extended string
types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects (remember that PDO for SQLServer is
experimental, if not totally unusable) is shotgun surgery, and just more
complexity to handle.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

I agree the spec could definitely do with some samples and detail.

At a start, what about defining 'N-prefix' so the reader doesn't have to trawl through references?!
And clarify whether the PR is for the generic solution or the earlier problem.

More importantly, what about allowing arbitrary quote delimiters?
https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html

Chris

--
http://twitter.com/ghrd

7 years ago by Adam Baratz — view source

unread

Merging responses here...

Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most

appropriate names?

Good point. Maybe instead:

PDO::PARAM_STR_NATL
PDO::ATTR_NATL_STRINGS
PDO::PARAM_STR_CHAR

How does this interact with different character sets used for the

connection, if at all?

I don't think that should matter. This is strictly a hint for the quote
functions to put an "N" at the beginning of their output.

DBAL maintainer here: before we introduce even more complexity into the PDO

stuff (which is already a maze), could a set of test cases be written, so
that stuff that is currently impossible to do without this RFC is
clearer/demonstrated?

The other RFC I mentioned included a similar solution to this problem. The
PR I put together for that should make this clear enough:
https://github.com/php/php-src/pull/2168

I'm asking because we didn't get any bug reports about extended string
types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects is shotgun surgery, and just more
complexity to handle.

I think of them more like flags, like PDO::PARAM_INPUT_OUTPUT, than
standalone types. Since you apply with a bitwise-OR, the addition would be
minimally invasive. And you wouldn't have to rewrite code if you switch
drivers. The flags would simply be ignored.

(remember that PDO for SQLServer is experimental, if not totally unusable)

I'm mainly interested in pdo_dblib, which is an officially maintained
extension (I'm the maintainer). I assume you're referring to pdo_sqlsrv?

More importantly, what about allowing arbitrary quote delimiters?

https://livesql.oracle.com/apex/livesql/file/content_CIREYU9

EA54EOKQ7LAMZKRF6P.html

This functionality seems orthogonal to what I'm describing. It would be
more appropriate to implement this as a driver-specific attribute for
pdo_oci. But since that driver doesn't support emulated prepares, I'm not
sure how much value it would have.

Thanks,
Adam

7 years ago by Christopher Jones — view source

unread

Merging responses here...
Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most appropriate names?
Good point. Maybe instead:

PDO::PARAM_STR_NATL

PDO::ATTR_NATL_STRINGS

PDO::PARAM_STR_CHAR

How does this interact with different character sets used for the connection, if at all?

I don't think that should matter. This is strictly a hint for the quote functions to put an "N" at the beginning of their output.
DBAL maintainer here: before we introduce even more complexity into the PDO stuff (which is already a maze), could a set of test cases be
written, so that stuff that is currently impossible to do without this RFC is clearer/demonstrated?
The other RFC I mentioned included a similar solution to this problem. The PR I put together for that should make this clear enough:
https://github.com/php/php-src/pull/2168 https://github.com/php/php-src/pull/2168
I'm asking because we didn't get any bug reports about extended string types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects is shotgun surgery, and just more complexity to handle.
I think of them more like flags, like PDO::PARAM_INPUT_OUTPUT, than standalone types. Since you apply with a bitwise-OR, the addition would be
minimally invasive. And you wouldn't have to rewrite code if you switch drivers. The flags would simply be ignored.
(remember that PDO for SQLServer is experimental, if not totally unusable)
I'm mainly interested in pdo_dblib, which is an officially maintained extension (I'm the maintainer). I assume you're referring to pdo_sqlsrv?
More importantly, what about allowing arbitrary quote delimiters?

https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html
<https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html>
This functionality seems orthogonal to what I'm describing. It would be more appropriate to implement this as a driver-specific attribute for
pdo_oci. But since that driver doesn't support emulated prepares, I'm not sure how much value it would have.

Isn't the same quoting functionality available via the quote() method? That's what the PR's tests use.

I don't think it's orthogonal. There are various ways to quote strings and a generic PDO solution should be flexible enough to handle all drivers.

Chris

Thanks,
Adam

--
http://twitter.com/ghrd

7 years ago by Adam Baratz — view source

unread

Isn't the same quoting functionality available via the quote() method?
That's what the PR's tests use.

I don't think it's orthogonal. There are various ways to quote strings
and a generic PDO solution should be flexible enough to handle all drivers.

Yes, they fit into the same general topic of string quoting, but I'd assign
different levels of importance to national charset literals and alternate
delimiters. Not being able to quote national charset literals means you
can't produce correctly formed queries with two drivers. My understanding
of alternate delimiters is that they make it easier to hand-writing
queries. The quote function may not generate the most human-readable
queries for some input, but the queries will be valid.

There are a couple other complexities for alternate delimiters. Not all
databases allow them and the options vary for each. For example,
PostgreSQL's only alternative is dollar-quoting[1]. If you think it's
important to handle this functionality, I think a separate RFC would be
more appropriate. My guess is instance/statement attributes would be the
better mechanism to control delimiters and you might want them to be
driver-specific.

Thanks,
Adam

[1]
https://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING

7 years ago by Adam Baratz — view source

unread

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

Thanks all for the feedback so far. I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.

Let me know if you have any new questions/concerns.

Adam

7 years ago by Andrea Faulds — view source

unread

Hi,

Adam Baratz wrote:

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

Thanks all for the feedback so far. I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.

The updated RFC is a lot clearer, thanks!

--
Andrea Faulds
https://ajf.me/

7 years ago by Marco Pivetta — view source

unread

Reading some random documents online (bear with me, doing it from the
phone), this seems to be irrelevant for MySQL, and an edge case dealing
with MSSQL. Is there a runnable functional test case demonstrating the
practical issue behind this addition?

Asking because of the same reasons I posted above.

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated
prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

Thanks all for the feedback so far. I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.

Let me know if you have any new questions/concerns.

Adam

7 years ago by Adam Baratz — view source

unread

Reading some random documents online (bear with me, doing it from the
phone), this seems to be irrelevant for MySQL, and an edge case dealing
with MSSQL. Is there a runnable functional test case demonstrating the
practical issue behind this addition?

I wouldn't characterize this as edge case for MSSQL. Implicit casts have
very real costs:
https://www.sqlskills.com/blogs/jonathan/implicit-conversions-that-cause-index-scans/

Part of my day job is supporting hundreds of engineers who use PHP to query
MSSQL. Our DBAs are very adamant about making sure we quote strings
correctly. We have a hackish solution for this. Since other pdo_dblib users
have asked for a solution, I wanted to work out a non-hackish solution that
could make it into master. Since these column types are part of SQL-92 and
the issue could also affect pdo_mysql, I wanted to make it a generic
solution.

I'm admittedly less familiar with MySQL than MSSQL, but this blog post has
some examples of implicit casts affecting performance:
http://code.openark.org/blog/mysql/beware-of-implicit-casting

Could you share more details around why you think this change is
irrelevant/unimportant? Or let me know how I should document things better
in the RFC?

Thanks,
Adam

7 years ago by Matteo Beccati — view source

unread

Hi Adam,

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

Thanks all for the feedback so far. I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.

Let me know if you have any new questions/concerns.

I'm sorry for being late to the party. I too have some doubts, but
having clarified the fact that national character types are a SQL-92
standard clears some of them.

However, I see no reference about the expected input/output encoding
(Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
match the internal encoding of the driver (e.g. UTF-16?)? What happens
if I try to quote a latin1 string?

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

7 years ago by Marco Pivetta — view source

unread

Hi Adam,

Based on some pain points with my team and things I've heard from
others,
I created an RFC to handle "national" character sets for emulated
prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

Thanks all for the feedback so far. I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.

Let me know if you have any new questions/concerns.

I'm sorry for being late to the party. I too have some doubts, but
having clarified the fact that national character types are a SQL-92
standard clears some of them.

However, I see no reference about the expected input/output encoding
(Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
match the internal encoding of the driver (e.g. UTF-16?)? What happens
if I try to quote a latin1 string?

Since I am still skeptical about this, I asked around and told people to
bind parameters with unicode strings and poke me back: works correctly.
So what is this addition doing exactly? Shouldn't this be treated as an SQL
Server BUG instead? Why push it on the toolchain?

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

7 years ago by Adam Baratz — view source

unread

However, I see no reference about the expected input/output encoding
(Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
match the internal encoding of the driver (e.g. UTF-16?)? What happens
if I try to quote a latin1 string?

I think this is mostly covered by my BC note: "These constants wouldn't
affect anything related to the character set used for connections." My only
intentions with my proposed change is to let people prepend an "N" to some
quoted values. The pdo_mysql and pdo_dblib quote functions are otherwise
ignorant of encoding. It's all bytes to them. There are different hooks to
set the encoding for a connection. I'm not aware of issues with either
extension dealing with multibyte characters in output.

If that doesn't make sense, pass on a code snippet and I can think through
how it would work.

Since I am still skeptical about this, I asked around and told people to

bind parameters with unicode strings and poke me back: works correctly.
So what is this addition doing exactly? Shouldn't this be treated as an
SQL Server BUG instead? Why push it on the toolchain?

It is true that you get the correct result right now. But this happens
because the DB will automatically cast values that are quoted incorrectly.
This addition would ensures that quoted values don't have an implicit cast
applied, which makes queries more expensive. I can put the links I shared
earlier into the RFC for easier reference.

Thanks,
Adam

7 years ago by Marco Pivetta — view source

unread

Hey Adam,

However, I see no reference about the expected input/output encoding

(Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
match the internal encoding of the driver (e.g. UTF-16?)? What happens
if I try to quote a latin1 string?

I think this is mostly covered by my BC note: "These constants wouldn't
affect anything related to the character set used for connections." My only
intentions with my proposed change is to let people prepend an "N" to some
quoted values. The pdo_mysql and pdo_dblib quote functions are otherwise
ignorant of encoding. It's all bytes to them. There are different hooks to
set the encoding for a connection. I'm not aware of issues with either
extension dealing with multibyte characters in output.

If that doesn't make sense, pass on a code snippet and I can think through
how it would work.

Since I am still skeptical about this, I asked around and told people to

bind parameters with unicode strings and poke me back: works correctly.
So what is this addition doing exactly? Shouldn't this be treated as an
SQL Server BUG instead? Why push it on the toolchain?

It is true that you get the correct result right now. But this happens
because the DB will automatically cast values that are quoted incorrectly.
This addition would ensures that quoted values don't have an implicit cast
applied, which makes queries more expensive. I can put the links I shared
earlier into the RFC for easier reference.

Thanks,
Adam

I've read the links, hence my skepticism and me labeling this as "yet
another way that SQL Server decides to make things harder and buggy". It is
a bug in SQL Server, unless I'm missing the reason for this to exist (or
maybe there was such a reason in 1991).

As for BC compliance, this will still break code, as current overrides to
prepared statements (in DBAL, specifically) directly compare the parameter
type to a constant (no bitmask comparison).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

7 years ago by Adam Baratz — view source

unread

I've read the links, hence my skepticism and me labeling this as "yet
another way that SQL Server decides to make things harder and buggy". It is
a bug in SQL Server, unless I'm missing the reason for this to exist (or
maybe there was such a reason in 1991).

One of the links is MySQL specific. Apart from that, it's not accurate to
characterize this as a bug with MSSQL. They used part of the SQL spec in an
intended way. Yes, it's a little more cumbersome than having a single
string type, but it doesn't help PDO users to wish other designs onto DBs.

As for BC compliance, this will still break code, as current overrides to

prepared statements (in DBAL, specifically) directly compare the parameter
type to a constant (no bitmask comparison).

I meant that this change won't break existing code. But yes, others may
need to modify their code to be compatible with this new feature. Within
pdo, a bitmask is applied -- see uses of the PDO_PARAM_TYPE macro. It's
probably worth replicating that in DBAL.

Thanks,
Adam

7 years ago by Matteo Beccati — view source

unread

I meant that this change won't break existing code. But yes, others may
need to modify their code to be compatible with this new feature. Within
pdo, a bitmask is applied -- see uses of the PDO_PARAM_TYPE macro. It's
probably worth replicating that in DBAL.

I'm sorry, I think it's too disruptive both for userland and drivers
developers. For very little gain, if I may.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

7 years ago by Adam Baratz — view source

unread

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

The vote closed and this RFC was accepted. Thanks all for your feedback and
votes.

Adam

7 years ago by Marco Pivetta — view source

unread

Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated
prepared
statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

The vote closed and this RFC was accepted. Thanks all for your feedback and
votes.

Adam

7 years ago by Christoph M. Becker — view source

unread

Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

--
Christoph M. Becker

7 years ago by Adam Baratz — view source

unread

Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

Sorry that you felt discussion was cut short. I tried to document the need
for this change as clearly as I could. It felt like we were going in
circles on this point, that you were going to vote against the RFC no
matter what. Let me know if I misunderstood something. This probably won't
be the last PDO-related RFC I write. I want to be an effective collaborator
with you and the rest of the community.

It should be possible to update DBAL so it will be unaffected by this
change. If you're still concerned about that, I'd be happy to discuss
off-list.

Thanks,
Adam

7 years ago by Rowan Collins — view source

unread

Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.
Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

I did think it was surprising that this RFC only had 9 votes registered,
when the one I opened around the same time currently has 29, so I wonder
if Marco wasn't the only one who overlooked it?

However, I received the notification fine, and it was picked up by the
SO chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be
that a lot of people were aware but decided to abstain.

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Levi Morrison — view source

unread

Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

I did think it was surprising that this RFC only had 9 votes registered,
when the one I opened around the same time currently has 29, so I wonder if
Marco wasn't the only one who overlooked it?

However, I received the notification fine, and it was picked up by the SO
chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that a
lot of people were aware but decided to abstain.

Regards,

--
Rowan Collins
[IMSoP]

--

We currently do not have any provision for requiring at least a
certain amount of votes, but in my opinion it would be prudent to do
so for cases like this. With only nine contributors voting and it
not even being unanimous I feel like it shouldn't pass. Anyone who is
gathering notes for a voting rework proposal should take note.

And of course RFCs should only be held to the agreed rules of the
time, so I'm not saying we should reject this RFC.

7 years ago by Jakub Zelenka — view source

unread

On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins rowan.collins@gmail.com
wrote:

Wait, when was the vote opened? I didn't receive any notification of
that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

I did think it was surprising that this RFC only had 9 votes registered,
when the one I opened around the same time currently has 29, so I wonder
if
Marco wasn't the only one who overlooked it?

However, I received the notification fine, and it was picked up by the SO
chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that
a
lot of people were aware but decided to abstain.

Regards,

--
Rowan Collins
[IMSoP]

--

We currently do not have any provision for requiring at least a
certain amount of votes, but in my opinion it would be prudent to do
so for cases like this. With only nine contributors voting and it
not even being unanimous I feel like it shouldn't pass. Anyone who is
gathering notes for a voting rework proposal should take note.

I completely disagree with this. If there is not enough votes, it means
that poeple either don't care (possibly don't have time or don't read
properly mailing list) or don't understand the proposed thing. I think it
shousld up to the maintainer to decide in such case and not to block a
feature because not enaugh people is interested in it. But even if we leave
it as it is (accept it with only few votes) it is still much better than
block it if there is no interest.

7 years ago by Levi Morrison — view source

unread

In

On Sun, Mar 19, 2017 at 7:50 AM, Rowan Collins rowan.collins@gmail.com
wrote:

Wait, when was the vote opened? I didn't receive any notification of
that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Adam announced the vote on March, 8th, see
http://news.php.net/php.internals/98447. The voting result was 8:1,
by the way.

I did think it was surprising that this RFC only had 9 votes registered,
when the one I opened around the same time currently has 29, so I wonder
if
Marco wasn't the only one who overlooked it?

However, I received the notification fine, and it was picked up by the SO
chat bot, https://php-rfc-watch.beberlei.de/, etc, so it may just be that
a
lot of people were aware but decided to abstain.

Regards,

--
Rowan Collins
[IMSoP]

--

We currently do not have any provision for requiring at least a
certain amount of votes, but in my opinion it would be prudent to do
so for cases like this. With only nine contributors voting and it
not even being unanimous I feel like it shouldn't pass. Anyone who is
gathering notes for a voting rework proposal should take note.

I completely disagree with this. If there is not enough votes, it means that
poeple either don't care (possibly don't have time or don't read properly
mailing list) or don't understand the proposed thing.

If this is the case then why on earth should it be in core?

I think it should up
to the maintainer to decide in such case and not to block a feature because
not enaugh people is interested in it.

If it's up to the maintainer then it didn't need an RFC anyway.

7 years ago by Rowan Collins — view source

unread

I completely disagree with this. If there is not enough votes, it
means that poeple either don't care (possibly don't have time or
don't read properly mailing list) or don't understand the proposed thing.

Yes, those are the most likely reasons. There is also the possibility
that for some technical or timing reason people missed the announcement.

I think it shousld up to the maintainer to decide in such case and not
to block a feature because not enaugh people is interested in it.

There is currently nobody authorised to make that decision, and granting
it to extension maintainers feels like a significant change to that
role. As I understand it, one of the big differences between a PECL
extension and a bundled one is that once in core, it's subject to
decision-making by the whole project, not the authors of the code.

But even if we leave it as it is (accept it with only few votes) it is
still much better than block it if there is no interest.

The entire RFC and voting process assumes that "no change" is the
default option - a language change requires two-thirds to make the
change, not two-thirds to reject it. If there were a "quorum" rule, it
would be entirely consistent for not enough votes to have the same
effect as an insufficiently large majority, and reject the change.

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Jakub Zelenka — view source

unread

I completely disagree with this. If there is not enough votes, it means
that poeple either don't care (possibly don't have time or don't read
properly mailing list) or don't understand the proposed thing.

Yes, those are the most likely reasons. There is also the possibility that
for some technical or timing reason people missed the announcement.

I think it shousld up to the maintainer to decide in such case and not to

block a feature because not enaugh people is interested in it.

There is currently nobody authorised to make that decision, and granting it
to extension maintainers feels like a significant change to that role. As I
understand it, one of the big differences between a PECL extension and a
bundled one is that once in core, it's subject to decision-making by the
whole project, not the authors of the code.

I don't really think that we any definition for mantainer role. Currently
it varies depending on the extension. For example you won't see many RFC's
in date ext which is very well maintained by Derick and most of the changes
are decided by him which I think is a very good thing and works very well.

But even if we leave it as it is (accept it with only few votes) it is

still much better than block it if there is no interest.

The entire RFC and voting process assumes that "no change" is the default
option - a language change requires two-thirds to make the change, not
two-thirds to reject it. If there were a "quorum" rule, it would be
entirely consistent for not enough votes to have the same effect as an
insufficiently large majority, and reject the change.

Sorry but I just don't agree with that. We are talking about a feature for
PDO that not many voters is interested in. That's completely different than
a language change. The interest in other core extensions is often the same.
If we had such rule on the minimal number of votes, one person could easily
block any progress on the any extension. It would not only slow down the
development but also annoy maintainers and people working on extension.
That's just a very bad idea IMHO.

Cheers

Jakub

7 years ago by Rowan Collins — view source

unread

I don't really think that we any definition for mantainer role.
Currently it varies depending on the extension. For example you won't
see many RFC's in date ext which is very well maintained by Derick and
most of the changes are decided by him which I think is a very good
thing and works very well.

[...]

Sorry but I just don't agree with that. We are talking about a feature
for PDO that not many voters is interested in. That's completely
different than a language change. The interest in other core
extensions is often the same.

Fair points. I'm not sure the RFC process as a whole works well for
specialist decisions - the same has come up with very technical Engine
changes.

I think this kind of breaks down into two questions:

Which changes need an RFC?
If a change does need an RFC, what level of support does it need?

I don't have particularly good answers, but "this change shouldn't have
needed an RFC in the first place" is a very different direction from
"after the RFC has been debated, this person should have a veto /
casting vote". I realise that's not what you were suggesting, though,
and I'm happy to go with "the current system is not really a problem".

If we had such rule on the minimal number of votes, one person could
easily block any progress on the any extension.

I am a little curious what you meant by this, though; I can't see how it
follows at all.

Regards,

--
Rowan Collins
[IMSoP]

7 years ago by Lester Caine — view source

unread

Sorry but I just don't agree with that. We are talking about a feature
for PDO that not many voters is interested in. That's completely
different than a language change. The interest in other core
extensions is often the same.

Fair points. I'm not sure the RFC process as a whole works well for
specialist decisions - the same has come up with very technical Engine
changes.

While PDO has gained some traction and some projects have switched over
to it, it would be useful to see what percentage of users do actually
take the PDO route and and those that still stay with other abstraction
options or remain with the generic drivers. My own preference is still
to ignore it as a base and stick with ADOdb, which does seem to be
growing again in support, but many projects have their own abstraction
layers which don't rely on PDO or for the likes of things like wordpress
only support MySQL anyway so don't need a cross database layer.

None of the 'improvements' added to PDO recently do anything to improve
it's standing, it still lacks a real reason for existing ...

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

7 years ago by Marco Pivetta — view source

unread

Sorry but I just don't agree with that. We are talking about a feature
for PDO that not many voters is interested in. That's completely
different than a language change. The interest in other core
extensions is often the same.

Fair points. I'm not sure the RFC process as a whole works well for
specialist decisions - the same has come up with very technical Engine
changes.

While PDO has gained some traction and some projects have switched over
to it, it would be useful to see what percentage of users do actually
take the PDO route and and those that still stay with other abstraction
options or remain with the generic drivers. My own preference is still
to ignore it as a base and stick with ADOdb, which does seem to be
growing again in support, but many projects have their own abstraction
layers which don't rely on PDO or for the likes of things like wordpress
only support MySQL anyway so don't need a cross database layer.

None of the 'improvements' added to PDO recently do anything to improve
it's standing, it still lacks a real reason for existing ...

Given that most installs of Doctrine DBAL (80%+) rely on PDO MySQL, that's
quite a lot of users: https://packagist.org/packages/doctrine/dbal/stats

PDO is currently the leading DB abstraction in PHP projects, regardless of
how horrible its API is.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

7 years ago by Lester Caine — view source

unread

Given that most installs of Doctrine DBAL (80%+) rely on PDO MySQL, that's
quite a lot of users: https://packagist.org/packages/doctrine/dbal/stats

PDO is currently the leading DB abstraction in PHP projects, regardless of
how horrible its API is.

https://w3techs.com/technologies/overview/content_management/all
Where does Doctrine fit into that picture?

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

7 years ago by Matteo Beccati — view source

unread

Wait, when was the vote opened? I didn't receive any notification of that
(and therefore didn't vote yet), and we were still telling you in this
thread that there are fundamental conceptual issues with the backing
reasoning.

Ha! I was wondering why you didn't vote just yet and here's the answer.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

[RFC] Extended String Types For PDO

Cheers

Cheers

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Cheers

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL