Your opinion is highly appreciated, Johannes. I feel that we will have to
implement this change as you are proposing.
I don't think I am rushing this change, because I believe is already late.
It should have been fixed in PHP 7 or PHP 8, but because very little people
use mysqli this extension
On February 27, 2021 7:29:43 PM GMT+01:00, Kamil Tekiela
wrote:
>> The code shown here
>https://www.w3schools.com/php/func_mysqli_connect.asp is
>relatively correct at the moment. Maybe not nice, but it handles the
>error.
>That is the second hit on google (after php.net manual) when
On Sat, Feb 27, 2021 at 5:24 PM Kamil Tekiela wrote:
> >
> > The issue is, as said, that this only happens in an error situation.
> > Thus if users only test "does my site still work after update?" (what
> > many do ...) won't notice this, till something fails, which would have
> > been caught
On 27/02/2021 18:10, Kamil Tekiela wrote:
Select * From products Where product_id = 'hello world'
If product_id is a column of type int, then the database will raise an
error about incompatible types.
No, this query would produce a warning. I am unaware of an SQL mode
that would
> The code shown here https://www.w3schools.com/php/func_mysqli_connect.asp is
relatively correct at the moment. Maybe not nice, but it handles the error.
That is the second hit on google (after php.net manual) when searching for
"php tutorial mysqli_conect") Most other books, tutorials, ... teach
>
> Select * From products Where product_id = 'hello world'
>
> If product_id is a column of type int, then the database will raise an
> error about incompatible types.
>
No, this query would produce a warning. I am unaware of an SQL mode that
would turn this warning into an error. Maybe I am
On 27/02/2021 16:57, Kamil Tekiela wrote:
If product_id is actually an integer column, this function is
technically broken: given a non-integer input, it will produce an
error
in the database.
I'm sorry, but I do not understand why would that code produce an
error. The value
On February 27, 2021 5:23:47 PM GMT+01:00, Kamil Tekiela
wrote:
>>
>> The issue is, as said, that this only happens in an error situation.
>> Thus if users only test "does my site still work after update?" (what
>> many do ...) won't notice this, till something fails, which would
>have
>>
>
> If product_id is actually an integer column, this function is
> technically broken: given a non-integer input, it will produce an error
> in the database.
>
I'm sorry, but I do not understand why would that code produce an error.
The value is properly escaped and formatted so there should be
On 27/02/2021 16:23, Kamil Tekiela wrote:
I don't see why this would be such an issue. If the code fails for any
reason then an error is produced. The error might be surprising, but it is
not something that would cause problems.
Just addressing this argument, not the proposal itself, a
>
> The issue is, as said, that this only happens in an error situation.
> Thus if users only test "does my site still work after update?" (what
> many do ...) won't notice this, till something fails, which would have
> been caught nice beforehand.
>
I don't see why this would be such an issue.
On Wed, 2021-01-27 at 15:17 +0100, Sebastian Bergmann wrote:
> Am 25.01.2021 um 11:03 schrieb Nikita Popov:
> > Fully support this proposal. Throwing exceptions is the right
> > default, it
> > matches what PDO does, and restoring the old behavior is one line
> > of code.
>
> I second that
Hi All,
If there are no more comments I would like to start voting on this RFC
soon. If you would like me to change something or if you want to discuss it
further please let me know.
Kind Regards,
Kamil
On Sun, 31 Jan 2021 at 18:20, Kamil Tekiela wrote:
> Hi All,
>
> I have updated the RFC at
Hi All,
I have updated the RFC at https://wiki.php.net/rfc/mysqli_default_errmode
and provided FAQ with the aim to explain your concerns as best as I could.
I have also added a section that explains all mysqli error reporting modes.
Best regards,
Kamil
Den 2021-01-28 kl. 01:31, skrev Kamil Tekiela:
I'm missing a thing here when we talk about "your code". I mean on
our
site we have third party libraries. They can typically have a release
schedule on a couple of releases each year. So all code is not up to
us to change. So
>
> I'm missing a thing here when we talk about "your code". I mean on our
> site we have third party libraries. They can typically have a release
> schedule on a couple of releases each year. So all code is not up to
> us to change. So how does this proposal adress that scenario when it's
> not
Den 2021-01-27 kl. 17:13, skrev Björn Larsson:
Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:
Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of
Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:
Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of mysqli_report() entirely useless?
I'm sorry, but I
>
> Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of mysqli_report() entirely useless?
I'm sorry, but I don't follow the train of thought? Why would it
On Wed, Jan 27, 2021 at 3:35 PM Christian Schneider
wrote:
> Am 27.01.2021 um 14:34 schrieb Nikita Popov :
> > I think if you wanted to introduce an additional diagnostic step, the
> way to go about it would be to issue a deprecation warning when creating a
> connection without mysqli_report()
Am 27.01.2021 um 14:34 schrieb Nikita Popov :
> I think if you wanted to introduce an additional diagnostic step, the way to
> go about it would be to issue a deprecation warning when creating a
> connection without mysqli_report() having been explicitly called beforehand.
Wouldn't this mean
Am 25.01.2021 um 11:03 schrieb Nikita Popov:
Fully support this proposal. Throwing exceptions is the right default, it
matches what PDO does, and restoring the old behavior is one line of code.
I second that emotion.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Tue, Jan 26, 2021 at 8:42 AM Christian Schneider
wrote:
> Am 26.01.2021 um 07:57 schrieb Alexandru Pătrănescu :
> > There will be other parts that will require testing, whatever you do.
> Trying to optimize this to reduce the 1 line quick fix that could be easily
> read in the documentation
I would like to say that I completely agree with George. The BC is minimal.
We are not introducing any new functionality or removing any either. We are
just changing a default setting that was always there. The only code that
would be affected is the one that is currently relying on the default
Am 26.01.2021 um 07:57 schrieb Alexandru Pătrănescu :
> There will be other parts that will require testing, whatever you do. Trying
> to optimize this to reduce the 1 line quick fix that could be easily read in
> the documentation at https://www.php.net/manual/en/migration81.php
>
On Mon, Jan 25, 2021 at 7:33 PM Christian Schneider
wrote:
> Am 25.01.2021 um 18:22 schrieb G. P. B. :
> > And yes I'm basically advocating for people to add
> mysqli_report(MYSQLI_REPORT_ERROR) (or even
> mysqli_report(MYSQLI_REPORT_OFF) if they fancy) to their setup, I'm even
> advocating for
Am 25.01.2021 um 18:22 schrieb G. P. B. :
> And yes I'm basically advocating for people to add
> mysqli_report(MYSQLI_REPORT_ERROR) (or even mysqli_report(MYSQLI_REPORT_OFF)
> if they fancy) to their setup, I'm even advocating for them to do it right
> now such that they can catch anything
On Mon, 25 Jan 2021 at 16:25, Christian Schneider
wrote:
> Am 25.01.2021 um 16:59 schrieb G. P. B. :
> > The BC break is totally minimal as it's a one line of code that needs to
> be added (and for all intent and purposes should already be done).
>
> That does not change the fact that it is a BC
Den 2021-01-25 kl. 17:25, skrev Christian Schneider:
Am 25.01.2021 um 16:59 schrieb G. P. B. :
The BC break is totally minimal as it's a one line of code that needs to be
added (and for all intent and purposes should already be done).
That does not change the fact that it is a BC break which
Am 25.01.2021 um 16:59 schrieb G. P. B. :
> The BC break is totally minimal as it's a one line of code that needs to be
> added (and for all intent and purposes should already be done).
That does not change the fact that it is a BC break which should be treated
accordingly.
You are basically
>
> Moreover, I'd rather we get rid of the warning modes all together as they
> make the least sense to me.
> Either you're handling the failures explicitly anyway and you use the
> silent mode, or you don't and want it to throw with the exception mode.
> The warning mode is literally the worst of
On Mon, 25 Jan 2021 at 15:41, Christian Schneider
wrote:
> Am 21.01.2021 um 23:46 schrieb Kamil Tekiela :
> > In fact, I don't really see this as a major breaking change. If any
> project
> > really needs the mysqli errors silenced then they can just set the error
> > mode back to OFF. The
Am 21.01.2021 um 23:46 schrieb Kamil Tekiela :
> In fact, I don't really see this as a major breaking change. If any project
> really needs the mysqli errors silenced then they can just set the error
> mode back to OFF. The change is aimed at new users, not existing projects.
> Silenced error
On Thu, Jan 21, 2021 at 12:05 AM Kamil Tekiela wrote:
> Hi Internals,
>
> Following my earlier announcement in
> https://wiki.php.net/rfc/improve_mysqli
> I decided to submit a dedicated RFC for the first proposal.
>
> This RFC proposes to change the default mysqli error reporting mode to
>
We should do the same with SQLite3 extension.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, 21 Jan 2021 at 21:51, Björn Larsson
wrote:
> If I understand this correctly, does it imply that a lot of
> legacy code that works today, will not work any longer and
> needs to change? Like:
> if ("mysqlierror") {
> "error handling"
> }
>
> If so I think that like in other RFC's
Den 2021-01-21 kl. 00:04, skrev Kamil Tekiela:
Hi Internals,
Following my earlier announcement in https://wiki.php.net/rfc/improve_mysqli
I decided to submit a dedicated RFC for the first proposal.
This RFC proposes to change the default mysqli error reporting mode to
exception mode. This
On Wed, Jan 20, 2021, at 5:04 PM, Kamil Tekiela wrote:
> Hi Internals,
>
> Following my earlier announcement in https://wiki.php.net/rfc/improve_mysqli
> I decided to submit a dedicated RFC for the first proposal.
>
> This RFC proposes to change the default mysqli error reporting mode to
>
38 matches
Mail list logo
