ext/mysqli: Throw error when mysql_stmt_data_seek cannot be executed#10419
ext/mysqli: Throw error when mysql_stmt_data_seek cannot be executed#10419kamil-tekiela merged 4 commits intophp:masterfrom
Conversation
cmb69
left a comment
There was a problem hiding this comment.
Thank you! Since this is a programmer error, it makes sense to throw an Exception, but that might be too strong to introduce in a minor version. What happens currently in this case? Just nothing?
|
|
||
| mysql_stmt_data_seek(stmt->stmt, offset); | ||
| if (mysql_stmt_data_seek(stmt->stmt, offset)) { | ||
| zend_throw_error(NULL, "The result set buffer is empty"); |
There was a problem hiding this comment.
Not sure about the wording; is there even a buffer in this case. Maybe "Result set is not buffered" (or something like that) gives a better clue about what's wrong.
There was a problem hiding this comment.
Yes, currently nothing happens. This is because until now we supported libmysql, which as stated above has this function implemented as void. Now, we are no longer limited by libmysql and we can start throwing an error.
I could also change this to a warning, but I don't see this happening very often and I don't it would be too much to have an error here.
In regards to the text, I wanted to find something rather vague. The error could happen because someone forgot to call store_result(), the PS has only been prepared but not yet executed, or the PS didn't produce any result set. Your suggestion fits the first reason, but not so much the rest. I welcome some brainstorming here.
There was a problem hiding this comment.
Should this be a mysqli_sql_exception? And is the result set empty because the offset points to something that doesn't exist? Then maybe a ValueError is better if one can determine ahead of time if the offset is invalid or not?
There was a problem hiding this comment.
mysqli_sql_exception should really only be reserved for client and driver errors, i.e. from MySQL or from mysqlnd. This should have been implemented in mysqlnd, but since PDO can still use libmysql, we cannot add it without creating an inconsistent behaviour.
The error was supposed to be similar to https://github.com/php/php-src/blob/master/ext/mysqli/mysqli_api.c#L327 where we can nicely check ahead of time if the function can be used. Here I would need to use this:
if (!stmt->stmt->data || !stmt->stmt->data->result || !stmt->stmt->data->result->stored_data) {
What do you think? Would that be cleaner?
There was a problem hiding this comment.
I have applied changes and also changed the error message. I kept it as a normal error to keep in line with the error from the other function. I don't think ValueError fits here because it's not about an incorrect argument.
There was a problem hiding this comment.
Sorry I meant, is it possible for the user to check ahead of time if the offset they provide is valid. But now that I see what the inspiration of this is I think it's fine.
There was a problem hiding this comment.
One more thing I am wondering about: should the function name be included in the error message?
There was a problem hiding this comment.
Probably makes sense to do so :)
|
I think it's too late for 8.3 as we are well past feature freeze and this is behaviour changes that should at least be emailed to internals. I think it makes sense to do it but might be better to target 8.4 |
c70fc7d to
89b3439
Compare
According to the MySQL standard
mysql_stmt_data_seekshould be a void function, but in mysqlnd it was always returningbool. In this case, it makes sense to check for an error condition and inform the mysqli user about incorrect usage.The only time this function returns false is if it's used on PS without a buffered result set, hence the text of the error message.