Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#173 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
mysql, php, wordpress
Área
backend, database

Línea de trabajo

Comienza verificando el límite de despliegue compatible para stock WordPress, db.php personalizado y hosts gestionados. Define cómo se asignan a eventos canónicos de persistencia las operaciones DML y DDL exitosas y revertidas, las transacciones, las identidades y los despliegues mixtos capturados/no capturados. La tarea estará completa cuando los criterios de aceptación estén documentados y probados, incluido el comportamiento compatible de wpdb, la recuperación, la detección de Doctor basada en capacidades, el manejo de hosts no compatibles y la compatibilidad sin cambios con SQLite.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
PHP
Estrellas
7
Forks
1
Merge medio
26 min
PR fusionados (30 d)
26

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Automattic/markdown-database-integration

Todos los issues de Automattic/markdown-database-integration

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.