Hi,
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
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-pdoI 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-12542Please let me know what you think.
Thanks,
Adam
Any thoughts on this one?
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-pdoI 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-12542Please let me know what you think.
Thanks,
AdamAny 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/
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-pdoI 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-12542Please let me know what you think.
Thanks,
AdamAny 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
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-pdoI 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-12542Please let me know what you think.
Thanks,
AdamAny 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
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
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
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/2168I'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
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
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
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-pdoThanks 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/
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-pdoThanks 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
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
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-pdoThanks 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/
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-pdoThanks 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
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
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
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
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/
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
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-pdoThe vote closed and this RFC was accepted. Thanks all for your feedback and
votes.Adam
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
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
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]
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.
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.
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.
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]
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
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]
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
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
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/statsPDO 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
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/