WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#43044 closed defect (bug) (maybelater)

Data inconsistencies

Reported by: robertorodes Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9.1
Component: Database Keywords:
Focuses: Cc:

Description

Hi there,

The point is that I’ve seen no trace of database ACID transactions usage or any other mechanism to ensure data is always (or eventually) consistent when performing write operations. This seems to me like a general and critical issue for any Wordpress based development or simply running Wordpress as is.

Since it’s pretty usual to find use cases in which a user request triggers multiple write operations, this might eventually lead to a broken database and unpredictable application behavior at some point.

Is there any implemented approach to manage database transactions or any other means to ensure data is consistent (eventually, at least)? Am I missing something?

Otherwise, do you have any plans on this matter?

Change History (1)

#1 @dd32
3 years ago

  • Component changed from General to Database
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Hey @robertorodes and welcome to Trac.

You're correct in that WordPress does not currently use Transactions, and does not have any database-layer restrictions set up to enforce data consistency.

WordPress, WordPress plugins, etc are encouraged to use the available API's and database funtions such as $wpdb->insert() and $wpdb->update() and checking their return values for whether a SQL command has succeeded or not.

There's also no guarantee given that the data will not be changed by another process between ProcessA writing it and then reading it.
If a plugin requires an absolute transaction to occur, they're free to initiate a transaction and save it at the end, it's just not "supported" in core.

I'm closing this as maybelater as while I do agree with you, there's currently no active plans to change how the database layer operates at this point. Discussions can continue with the ticket closed, and if a committer feels dedicated to it, they can re-open it when the time comes to work on it.
WordPress also currently supports a wide range of MySQL versions (and variants) and table types, not all of which support transactions AFAIK. There's also the database dropins available which use MSSQL or PostgreSQL & SQLite.

Note: See TracTickets for help on using tickets.