Opened 10 years ago
Last modified 5 years ago
#31042 new enhancement
WPDB field_types Variable Too Broad?
Reported by: | njkrut | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Database | Keywords: | |
Focuses: | Cc: |
Description
I was wondering if it might make sense to tie the field_types format definitions to tables and columns instead of just columns. As people use WordPress more there may be situations like the one I encountered today where columns of their enhancement tables overlap with those of WordPress' default tables. In my situation my user_id was more of a guid so it was a string that was being formatted to a decimal. While this might not be a common problem with the overhead it would take to change it to a multidimensional array it might make sense.
If this is something others would find useful or practical I would be happy to rework the code.
Change History (2)
#2
in reply to:
↑ 1
@
10 years ago
Replying to nacin:
In general,
$field_types only
benefits WordPress core, as you'd generally want to specify formats for values (for INSERT, UPDATE) and where values (for UPDATE, DELETE). So, while core may do:
$wpdb->update( $wpdb->users, array( 'user_activation_key' => $key, 'ID' => $id ) )A plugin should always do:
$wpdb->update( 'custom_table', array( 'user_activation_key' => $key, 'ID' => $id ), array( '%s', '%d' ) )I do see the benefit of allowing it so a plugin can register their field types with WordPress, but as it stands right now, that's not how it's designed... It's mostly just an internal thing, designed only for core columns.
I don't see why plugins should be required to force a format to every column on inserts and updates. I have built a custom REST addon for WordPress so my insert and update queries aren't always as simple as your examples. My problem is not the benefit of the $field_types
but the issue when you have overlapping fields on a $wpdb->insert
call... Such as user_id
In general,
$field_types only
benefits WordPress core, as you'd generally want to specify formats for values (for INSERT, UPDATE) and where values (for UPDATE, DELETE). So, while core may do:A plugin should always do:
I do see the benefit of allowing it so a plugin can register their field types with WordPress, but as it stands right now, that's not how it's designed... It's mostly just an internal thing, designed only for core columns.