Make WordPress Core

Opened 6 years ago

Last modified 6 years ago

#44814 new enhancement

User table same schema, single and multisite

Reported by: spacedmonkey's profile spacedmonkey Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3
Component: Networks and Sites Keywords: dev-feedback needs-patch
Focuses: multisite Cc:

Description

Currently, there is a difference between the users table database schema between single and multisite. I think this is problematic, as it is an unnecessary difference between single and multisite. It means conditional logic that is unnecessary and could make issues for developers querying the users table.

Attachments (1)

44814.diff (2.0 KB) - added by spacedmonkey 6 years ago.

Download all attachments as: .zip

Change History (5)

@spacedmonkey
6 years ago

#1 @jeremyfelt
6 years ago

Thanks @spacedmonkey. I haven't looked closely at the schema differences, but this seems like it could be a duplicate of #39814.

#2 @spacedmonkey
6 years ago

@jeremyfelt no those tickets are not the same.

For some reason in multisite, there are two different fields for the users table, spam and deleted. I don't know why this is. @johnjamesjacoby mentioned it had something to do with .com, but I dont know.

#3 @johnjamesjacoby
6 years ago

#34316.

Early on (2006ish?) it was decided that maintaining the users database schema across all projects (GlotPress, bbPress, BackPress, WordPress) was more important than hunting down performance improvements to it.

As a result, it was easier to add these new columns for multisite, to avoid changing user_status to a string like post_status across all projects.

Today, I think that old thinking no longer applies, but the next reason not to change these is because index updates to large users tables will take minutes-to-hours to finish. WordPress.com likely wouldn’t even run the update, since it would require pausing sign-ups.

Related: The last time I broke WordPress.org, it was due to a users table change from multisite to single site (and a missing DO_NOT_UPGRADE_GLOBAL_TABLES check), and it locked everything for around 12 minutes.

#4 @spacedmonkey
6 years ago

Thanks for the history lesson on this one @johnjamesjacoby

My plan was to make single site user tables the same as multisite’s. For those running at scale for single site, they will not be effected if they have don’t upgrade global tables. Large multisite will not be effected as this patch only effect single site.

Note: See TracTickets for help on using tickets.