Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Add full-primary MySQL mutation capture through a delegating database backend

オープン
  • 何か問題がありますか？
#173 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
mysql, php, wordpress
領域
backend, database

調査の方向性

まず、stock WordPress、カスタム db.php、マネージドホストでサポートされるデプロイ境界を確認します。成功した DML および DDL とロールバックされた DML および DDL、トランザクション、アイデンティティ、ならびにキャプチャ済み/未キャプチャの混在デプロイが、正規の永続化イベントにどのように対応付けられるかを定義します。受け入れ基準が文書化され、テスト済みであることが完了の条件です。これには、互換性のある wpdb の動作、リカバリ、capability ベースの Doctor 検出、未サポートホストの処理、変更されていない SQLite 互換性が含まれます。

索引モデルが issue の本文から書いたものです。

説明

enhancement

Problem

The MySQL content backend can make selected posts file-primary through WordPress lifecycle events, but full MDI primary semantics also cover options, users, comments, schemas, and arbitrary plugin tables. Those writes can bypass WordPress content hooks and require successful database-level mutation capture.

This is a later child of #57. It follows the MySQL content backend and does not block it.

Desired Capability

Add a delegating MySQL backend that captures successful mutations at the WordPress database boundary while preserving normal MySQL execution:

WordPress wpdb
      -> MDI delegating backend
      -> normal MySQL execution
      -> normalized successful mutation events
      -> canonical persistence core

The backend owns MySQL result normalization, transactions, schema introspection, affected-resource discovery, and mutation capture. The canonical core remains SQL- and database-neutral.

Required Design Evidence

Before implementation, verify the supported deployment boundary for stock WordPress, custom db.php, and managed hosts. The backend must define:

  • which direct $wpdb writes are captured;
  • transaction and rollback timing;
  • read-after-write behavior;
  • schema DDL handling;
  • auto-increment identity reconstruction;
  • mixed captured/uncaptured deployment behavior;
  • operational recovery when canonical persistence fails after MySQL succeeds.

Acceptance Criteria

  1. Direct plugin $wpdb DML and DDL mutations produce normalized canonical persistence events after successful execution.
  2. Failed and rolled-back SQL produces no canonical state change.
  3. Options, users, comments, taxonomy state, and representative plugin schemas/tables reconstruct from canonical files into an empty supported MySQL database.
  4. Existing callers observe compatible wpdb return values, errors, insert IDs, row counts, timing, and query logging.
  5. Mixed-version deployment behavior is documented and tested.
  6. Doctor distinguishes full-primary MySQL from content-primary MySQL using capabilities, not mode-name assumptions.
  7. Hosts that cannot install the required database boundary receive an explicit unsupported result and retain content-primary operation.
  8. SQLite compatibility remains unchanged.

AI Assistance

OpenAI GPT-5.6 Sol via OpenCode was used to inspect MDI's existing full-state persistence guarantees and draft this issue. Chris Huber directed the architecture and remains responsible for the proposed capability boundary.

主要言語
PHP
スター
7
フォーク
1
平均マージ
26分
マージ済み PR（30日）
26

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Automattic/markdown-database-integration のほかの issue

Automattic/markdown-database-integration の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。