My previous email had an ambiguous subject line. My apologies.
I've moved my RFC to the voting phase.
The proposal:
Add a function that exposes the warning count of the most recent
statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int
straight from the MySQL driver. This fixes the open bug at:
https://bugs.php.net/bug.php?id=51499.
Voting will be open till 2020-07-21
https://wiki.php.net/rfc/pdo-mysql-get-warning-count
The pull request (with tests) is here:
https://github.com/php/php-src/pull/6677
Thanks for your time!
Daniel
The proposal:
Add a function that exposes the warning count of the most recent
statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int
straight from the MySQL driver. This fixes the open bug at:
https://bugs.php.net/bug.php?id=51499.Voting will be open till 2020-07-21
The proposed vote declares that that:
“Yes” means this pull request should be merged (pending code review). “No” means we don't want PDO to expose MySQLs warning count.
This seems like a false dichotomy. What response would be appropriate for "exposing the MySQL warning count in PDO is fine, but this isn't the right way to do it"?
I'm not eligible to vote, but speaking for myself, I'd prefer a more generic mechanism for exposing metadata about queries -- not one that's specific to MySQL, nor one which only exposes a warning count. For example, MySQL also exposes some flags for statements where no index was used, and SQLite has functions to obtain the expanded SQL for a statement or to check if it's a read-only operation; all of these, along with the MySQL warning count, would fit nicely into a more generic PDO statement metadata API.
Would it be possible to amend the voting statement to:
“Yes” means this pull request should be merged (pending code review). “No” means the pull request should not be merged.
without invalidating existing votes? It would be unfortunate for this vote to be interpreted as a rejection of any future PDO API which happens to include the MySQL warning count.
Voting will be open till 2020-07-21
This date has passed, yet the vote is still ongoing.
Daniel, could you please close the vote and do the usual follow up tasks?
If Daniel is unavailable, what is the process for someone else doing
those things?
Is there a process in place for RFCs that address bugs in bugs.php.net if
they have a passing vote to mark the bug as "FIXED in version xx.xx.xx" or
if the RFC doesn't pass mark the bug as "WONTFIX"?
On Mon, Jul 26, 2021 at 6:49 AM Peter Cowburn petercowburn@gmail.com
wrote:
Voting will be open till 2020-07-21
This date has passed, yet the vote is still ongoing.
Daniel, could you please close the vote and do the usual follow up tasks?
If Daniel is unavailable, what is the process for someone else doing
those things?
Den man. 26. jul. 2021 kl. 15.49 skrev Peter Cowburn petercowburn@gmail.com:
This date has passed, yet the vote is still ongoing.
Daniel, could you please close the vote and do the usual follow up tasks?
If Daniel is unavailable, what is the process for someone else doing
those things?
I took the liberty to close the vote and moved the RFC to the
Withdrawn section given its supposedly abandoned status
--
regards,
Kalle Sommer Nielsen
kalle@php.net