WordPress.org

Make WordPress Core

Opened 16 months ago

Last modified 16 months ago

#39814 new defect (bug)

wp_usermeta uses umeta_id instead of meta_id

Reported by: johnjamesjacoby Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 0.71
Component: Database Keywords: 2nd-opinion dev-feedback close
Focuses: Cc:

Description

The wp_usermeta database table has an inconsistency compared to all other meta-data tables, in that it's meta_id column is named umeta_id. It has always had this, but there hasn't been a ticket on Trac specifically for this that I could see (even if we decide to close it right away.)

This discrepancy requires work-arounds in WordPress core, specifically in the meta-data API. (See #11627.)

There are a few ways to look at this:

  • Legacy, so we're stuck with it
  • Benign, so leave it alone
  • Changing it may cause more harm than good, so ignore it

Personally, it's uniqueness bothers my OCD more than supporting a schema change would, so my vote is to: rename it in a database upgrade, upgrade core's related database queries, and add pre-flight string-replace to WPDB to protect custom queries from failing.

Change History (2)

#1 @1naveengiri
16 months ago

  • Keywords dev-feedback added

I like the point. It should be meta_id as we already following same name for all meta-data tables. It should considered as Bug. even it is not any issue with functionality but still for standards.

#2 @dd32
16 months ago

  • Keywords close added

In an ideal world everything would be named consistently - but it's not, instead we put consistent API's in front of it so that others shouldn't need worry about these small nuances.

I don't think we should be changing anything here, definitely not renaming the column, as it potentially breaks compatibility while not actually gaining much (code already exists to work around the name difference). We could work around queries using the old column name - but doing so doesn't seem worth it.

If there's any locations in the meta api where we return the key umeta_id and meta_id in other cases, then updating it so as to cause usermeta to return [umeta_id => ..., meta_id => ..., ...] would seem sane - once again, so as to add a consistent API.

Note: See TracTickets for help on using tickets.