WordPress.org

Make WordPress Core

Opened 2 months ago

Last modified 7 weeks ago

#41956 new enhancement

Errno in $wpdb

Reported by: LeonN1960 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Database Keywords: has-patch needs-refresh
Focuses: Cc:

Description

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

Attachments (5)

41956.diff (61.0 KB) - added by munyagu 2 months ago.
41956.2.diff (1.4 KB) - added by munyagu 7 weeks ago.
wp-db.php (93.7 KB) - added by LeonN1960 7 weeks ago.
my db file with last_errno
41956.3.diff (4.9 KB) - added by munyagu 7 weeks ago.
41956.4.diff (4.7 KB) - added by munyagu 7 weeks ago.
remove unrelated fixes

Download all attachments as: .zip

Change History (18)

#1 @munyagu
2 months ago

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"]

@munyagu
2 months ago

#2 @johnbillion
8 weeks ago

  • Keywords has-patch needs-refresh added
  • Version 4.8.2 deleted

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!

Last edited 8 weeks ago by johnbillion (previous) (diff)

@munyagu
7 weeks ago

#3 @munyagu
7 weeks ago

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

#4 @LeonN1960
7 weeks ago

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

#5 @munyagu
7 weeks ago

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.

#6 @LeonN1960
7 weeks ago

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

#7 @munyagu
7 weeks ago

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

@LeonN1960
7 weeks ago

my db file with last_errno

#8 @LeonN1960
7 weeks ago

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
7 weeks ago

#9 @munyagu
7 weeks ago

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
7 weeks ago

remove unrelated fixes

#10 @LeonN1960
7 weeks ago

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

#11 @munyagu
7 weeks ago

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.

#12 @LeonN1960
7 weeks ago

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

#13 @munyagu
7 weeks ago

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

Note: See TracTickets for help on using tickets.