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

Settle the projection boundary: what belongs in frontmatter vs the table store

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
活発
技術スタック
php, wordpress
領域
database

調査の方向性

Start by reading the frontmatter profile, wordpress_meta(), _tables/postmeta.json, and the reconciliation contract described in the issue. Compare the proposed projection boundary with the portability counter-case and the native runtime's bounded SELECT restriction. Done means choosing one source of truth, defining projected fields, and documenting the boundary.

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

説明

MDI currently runs two storage models at once, and that overlap is the source of avoidable complexity.

The two models

SQL driver over the filesystem. _tables/*.json mirrors WordPress tables — postmeta.json, termmeta.json, options, actionscheduler_*, datamachine_* — 32 table files, plus _options/ and _indexes/. On one live install that is ~25 MB, ~68 MB and ~3.8 MB respectively. In this model markdown is a projection of the posts row.

Markdown is the database. Frontmatter carries everything about a post; there are no shadow tables.

Both are coherent. Running both means some facts have two possible homes, and the meta/terms blocks in the frontmatter profile partially duplicate what _tables/ already owns.

Why it matters concretely

#421 and its revert #423 both came from this ambiguity. The symptom looked like data loss, the allowlist in wordpress_meta() looked like the cause, and _tables/postmeta.json — which already held private keys — was not consulted. A clear boundary would have made that a five-second question instead of a merged PR and a release.

It also drives the reconciliation contract: the WP-side snapshot can only meaningfully diff against markdown for facts markdown is supposed to hold. Include more and you manufacture permanent drift.

Proposal to evaluate

Markdown files are the human-editable projection of the posts row: title, slug, status, dates, parent, content — the things a person edits or that identify the row. Everything else, including post meta and terms, lives in _tables/, which is the database. One fact, one writer.

If adopted:

  • Remove meta and terms from the frontmatter profile rather than widening them.
  • Define the reconciliation contract as comparing only projected fields.
  • Document the boundary so future changes do not relitigate it per-field.
  • Revisit whether the native runtime's "bounded single-table SELECT only" restriction is the right shape once _tables/ is unambiguously the database. A general SQL driver over those tables — JOINs included — is a different and arguably simpler contract than a bounded special case.

The counter-case worth arguing: frontmatter meta is portable and human-visible, which a JSON table is not. If that portability matters, say so explicitly and make the table store the derived side instead — but pick one.

AI disclosure

Written by Claude Sonnet 4.5 via opencode, prompted by the operator asking why a second writer had been added when the table store already existed. Evidence above is from a live install inspected during that session.

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

環境構築

このプロジェクトには開発コンテナ、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 を短くまとめたダイジェスト。