Errno in $wpdb

[LeonN1960]

Since I use referential integrity in my plugin, there will be situation that the referential integrity will be violated. But, unfortunately there is not a proper way to identify the reason of the violation in $wpdb->last_error. It is only text, and could differ in diffenrent languages I assume.

Since Mysqli contains also the errno, would it be possible to also present the errno as part of the result. In that case I could check the errorno to be 1451 for referential integrity violation.

In my opinion a usefull enhancement of the WPDB class. If any help needed, just contact me

[munyagu]

I think that it will be useful for problem solving if an error code is output.
For the beginning, I tried to output in the following format.

 [code:"1146",message:"Table 'db_test.wp_options' doesn't exist"]

[johnbillion]

Thanks for the patch, @munyagu. Can you regenerate the patch without all the unrelated formatting fixes please?

Aside: My ​Query Monitor debugging plugin converts a database error into a WP_Error object, stores that along with the query data, and exposes it via its UI. @LeonN1960 you may want to give it a try. Edit: It doesn't log and expose the errno. I'll add that to the next version!

[munyagu]

I sent a patch without checking well.
I have regenerated the patch.

[LeonN1960]

Hi,

Thanks for your quick solution. I checked the content, but I am not sure whether I understand it well.
Is it true that you combine the errror-number and error-message together in the field last_error?
Did you also consider to put it in a new filed 'last_errno'? or does this have to much impact?

Best regards,
Leon

[munyagu]

Thank you for reply, @LeonN1960.

Yes, I thought about it.
$last_ error field is considered to be directly referenced, because it is public.
So, I thought it was more convenient to output the error code in the same usage as before by stuffing into $last_error field.
Also, wp-db.php has a conditional branch if ($this->last_error) { I thought that the change based on $last_error field is more convenient for users.

However, if originally, $last_errno field should be added (and do not change last_error) as you say, and it seems that keep the impact on users to a minimum.

I will try it.

[LeonN1960]

In my draft version at home, it was done in a minute. But since I am not a very experinced builder I prefer you make the generic solution.
For me it would be nice to separate error number and last error, since I do not want to present the error number to the end user. Therefor I prefer to log the error number to my plugin-logging, only visible for experts

Any help needed? Just contact me

[munyagu]

@LeonN1960 I'm not a very experienced builder too.
Please post your patch.

[LeonN1960]

my db file with last_errno

[LeonN1960]

sorry, but I do not know how to upload only the difference file.
If you search in the file for last_errno you will find all my updates.

Thnxs in advance

[munyagu]

I changed how to hold the error info so that it should be, I think.
It was impossible to judge whether these change were all necessary or not.

$wpdb holds error information in $last_error field and $EZSQL_ERROR global variable.

$last_error left as it was as legacy.
Newly added $last_err_no and $last_err_msg, and created a getter for each.
($last_err_msg may have used $last_error as it is, but ...)
Also added a get_last_error function to retrieve only error info as an array.

$EZSQL_ERROR also adds an error number at the end.

[munyagu]

remove unrelated fixes

[LeonN1960]

Hi munyagu,

Thanks for the adjustment. I want to try it, but could you please help me how to implement this ? Or perhaps send me the complete wp-db.php?

Thanks in advance

[munyagu]

Hi, LeonN1960.

I don't understand why you want to use this code because the possibility of merged intact is very low.

Especially since this patch is too fat compared to its purpose (output error code as debug information).
Besides changing this patch, it is also necessary to write the test code ​​for the added function or global variable.
I think it is still necessary to discuss how this function is implemented.

Then I destroyed my environment for another patch creation.
If you really want to try this patch, try using svn or see the contents of the patch and merge it into your source.

[LeonN1960]

Ahh, I think I uderstand better now. Sorry, this is the first time I participate in these type of discussions.
As I understand you will integrate this improvement in one of upcoming releases? Any idea when this will happen?

Best regards,
Leon

[munyagu]

I have no idea if this feature will be released or not.

[birgire]

41956.5.diff​ refreshes the patch, adjusts according to code standard and adds the tests:

• test_get_err_no_should_return_zero_when_no_errors()
• test_get_err_no_should_return_error_code_from_last_error()
• test_get_err_msg_should_return_empty_string_when_no_errors()
• test_get_err_msg_should_return_message_from_last_error()
• test_get_last_error_should_return_false_without_errors()
• test_get_last_error_should_return_error_code_and_msg_from_last_error()

Here I generated and used specific error codes/messages that seems to be shared between MySQL and MariaDB:

​https://mariadb.com/kb/en/library/mariadb-error-codes/#shared-mariadbmysql-error-codes

We can also adjust the tests if that's not the case.

[hywan]

This patch is useful! Keep going :-).