docs: reject the unread workspace flag in the contract, and demote row editing to the backlog (#288, #279, #284) - #311
Merged
Conversation
…w editing to the backlog Three deferred items, triaged by what each one costs a reader rather than by how much work it is. None of them changes behaviour. **#288 — `WorkspaceFeatures.inlineEditing` now says it does nothing.** It is declared in a published interface, a host can set it, and nothing reads it: the embedded workspace hard-codes `editingEnabled={false}` at both grid call sites and its adapter cannot carry the `skipSafety` flag the standalone path relies on. The issue offered removing the field or implementing it; both are wrong right now — removing it breaks every host that sets it, implementing it waits on #279. The third option is the one the issue was actually asking for: a declared capability that is neither implemented nor rejected is the state to avoid, so this rejects it explicitly, in the place a host reads the contract. Verified in the built package: the tag is on the field in `dist/workspace.d.ts`. **#279 — per-dialect row editing moves to `docs/BACKLOG.md`.** It is deferred work rather than a defect, because #269 already made the software honest about it: the `supportsInlineRowEdit` gate hides the control wherever the shared `UPDATE` shape does not fit, so nothing is broken and nobody is misled. The entry keeps what the issue knew — the per-provider forms, the two constraints inherited from #269 (one request per row, heuristic key detection), and that whether row editing should be universal is a product decision. That is a demotion, the reverse of this file's documented promote-to-an-issue rule, so the rule now states both directions and where the line is: an understood, unscheduled item that breaks nothing belongs here, and a defect a user can hit stays an issue, because closing one of those hides a limitation instead of deferring it. **#284 — stays open, and the generator now says what it does not cover.** The schema-diff output can be unrunnable outside PostgreSQL, which a user meets as broken SQL, so it keeps its issue. What it did not have was any statement of the gap at the call site: `generateMigrationSQL(diff, dialect)` takes a dialect whether or not the path in question uses one. The module header now names the one path that is dialect-aware and the four that are not.
|
This was referenced Aug 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #288. Closes #279.
Three deferred items, triaged by what each one costs a reader rather than by how much work it is. No behaviour changes — a deprecation tag, a backlog entry and a module header.
The context: these three are not scheduled while the product's attention is elsewhere. Leaving them open unanswered for months is its own cost, but so is closing a defect that still bites. So they are not treated the same way.
#288 — the flag now says it does nothing
WorkspaceFeatures.inlineEditingis declared in a published interface, a host can set it, and nothing reads it:StudioWorkspacehard-codeseditingEnabled={false}at both grid call sites, and the embedded query adapter'sexecuteQuerytakes no execution options, so it could not carry theskipSafetyflag the standalone inline-edit path relies on (#269) even if a caller reached it.The issue offered two resolutions — remove the field, or implement it. Both are wrong right now: removing it stops every host that sets it from compiling, and implementing it waits on #279. So this takes the option the issue was actually asking for. Its own words are that "a declared capability that is neither implemented nor rejected is the state to avoid" — this rejects it, explicitly, where a host reads the contract.
Verified in the built package rather than assumed: the tag lands on the field in
dist/workspace.d.ts, so a host's editor strikes it through and says why.#279 — moved to
docs/BACKLOG.mdand closedDeferred work, not a defect. #269 already made the software honest about it: the
supportsInlineRowEditcapability hides the control wherever the sharedUPDATE <table> SET <col> = <val> WHERE <pk> = <val>shape does not fit, so nothing is broken and no user is misled — the feature is simply absent on ClickHouse, Druid, MongoDB, Redis, Couchbase and the embedded engine.The backlog entry keeps everything the issue knew: the per-provider forms (ClickHouse's
ALTER TABLE … UPDATE, MongoDB's document path, append-only engines keeping the capability false), the provider-triad obligation, and the two constraints inherited from #269 — one request per edited row, and primary-key detection that should come from the schema rather than from column names. It also records that whether row editing should be universal at all is a product decision.That is a demotion, the reverse of the file's documented promote-to-an-issue rule, so the rule now states both directions and where the line falls:
#284 — stays open, and the generator now states its gap
Not closed, and not backlogged. The schema-diff generator can emit migration SQL that is unrunnable outside PostgreSQL — a
BEGIN;/COMMIT;wrapper that MSSQL cannot parse and Oracle reads as a PL/SQL block,ADD COLUMN/DROP COLUMNin one shape for eleven type ids, andDROP INDEX IF EXISTSfallbacks Oracle rejects. A user meets that as broken SQL, so it keeps its issue; closing it would hide a limitation rather than defer it.What it lacked was any statement of the gap where a developer meets it.
generateMigrationSQL(diff, dialect)takes a dialect whether or not the path in question uses one, so the partial coverage is invisible from a call site. The module header now names the one path that is dialect-aware (the modified-column path, #269) and the four that are not.The issue itself is getting a
help wantedlabel and a comment recording that it is unscheduled, well specified, and that the emitted forms want checking against a live MSSQL and Oracle before they are settled — the way #264 and #265 were.Verification
bun run format·bun run lint(0 errors; no warning touches either changed source file) ·bun run typecheck·bun run knip·bun run test(exit 0) ·bun run build·bun run build:lib+bun run attw·bun run coverage:check→ 29254/29254 lines (100.00%).No tests were added: nothing executable changed. The one claim worth checking mechanically — that the deprecation reaches consumers — was checked against the built
dist/workspace.d.ts.