Conversation
These are external links (marketing site / blog / third-party) that still point at pre-migration URLs and 404 through our existing _redirects catch-alls: - /docs/guides/installation(/*) — old GitBook path; canonical is /docs/introduction/installation. - /docs/sql-reference/supported-clients/spreadsheets — the source page was removed upstream as out of date (dolthub/docs@8343826) with no replacement; send it to the Supported Clients index instead of 404. - /docs/products/dolthub/api/sql — moved under v1alpha1/ when v2 was introduced. The retool-feature-flag-app-export.json blog resource from the same report is left alone — that's a missing blog asset, not a docs URL. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fix: redirect three legacy DoltHub links that 404 in production
Pulls v2.yaml from ld's taylor/api-v2-sql-write branch, which turns
POST /api/v2/databases/{owner}/{database}/sql into a dual-purpose
endpoint: a SqlReadRequest body behaves as before, a SqlWriteRequest
body ({from_branch, to_branch, query}) kicks off an async write.
The generator didn't support oneOf request-body schemas — it silently
dropped the request-body table and example payload for any endpoint
shaped that way. Fixed generate-api-v2.mjs to render one table/example
per oneOf variant, labeled by schema title, and regenerated
database.md and models.md. Also fixed a stale hand-written link in
README.md's index (old operationId/title for this endpoint).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Merged origin/main into ld's taylor/api-v2-sql-write locally to pick up its "drop stale plan-phase reference" cleanup. No schema or endpoint changes — just four description strings in models.md losing their internal (§5.x) plan-doc references. Note: that merge on the ld side has an unresolved conflict in sql.ts (application code, not the spec) — left for manual resolution there, not touched from this repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Update cli.md
The endpoint-mapping table was missing the async write flow entirely
(POST .../write/{from_branch}/{to_branch} and its GET .../write poll
endpoint), left out before v2 had a write-capable SQL endpoint. Map
them to the new dual-purpose POST .../sql (runSqlPost) and the
standard operations-polling pattern used elsewhere in this table.
The v2 index (README.md) already covers this endpoint correctly from
an earlier commit — no change needed there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ld's api-v2-sql-write branch merged to main (#23820) and was then redesigned in a follow-up (#23932, "split POST /sql into read-only + new /sql-writes"): the dual-purpose oneOf body on POST /sql is gone. POST /sql is read-only again (runSqlReadQueryPost); the async write moved to its own POST /sql-writes (runSqlWriteQuery). Pulled the latest v2.yaml from ld-clone's main and regenerated. Updated README.md's index and migration.md's endpoint-mapping table to point at the new operation. Also fixes a generator bug: the sub-resource grouping in database.md didn't know about the new "sql-writes" path segment, so it fell back to a raw "## sql-writes" heading instead of folding into the existing "## SQL" section. The spec itself also picked up its own cleanup upstream — the stale "phase-4" internal-jargon wording I flagged earlier is gone, replaced with concrete endpoint references. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The redesign in api-v2-sql-split replaced the one endpoint that needed this (dual-purpose POST /sql) with two separate single-schema endpoints. The only oneOf left in the spec is nested inside a property (CreateBranchRequest.from), which this code never handled anyway. Reverting to the simpler single-schema requestBodySection/curlExample — confirmed the regenerated output is byte-identical to before this revert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pulled the latest v2.yaml from ld-clone's main (#23937, api-v2-sql-read-body-query). SqlWriteRequest's SQL-statement field is now `q`, matching SqlReadRequest, instead of `query`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tables with long unbroken <code> cells (e.g. the v2 migration guide's endpoint-mapping table) overflowed the content column with no way to see the clipped text — table had no horizontal scroll affordance, unlike <pre> blocks which already use overflow-x-auto. Add a rehype plugin that wraps every rendered <table> in a .table-scroll div, and give that wrapper overflow-x-auto (moved the mb-4 spacing there too, off the table itself). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… paths Swap the scroll-wrapper approach for wrapping: drop the rehype table-wrap plugin and instead let cell content break (overflow-wrap: anywhere) with table-layout: fixed so columns share the container width predictably. Also drop the redundant /api/v2 prefix from the v2 column of the migration guide's endpoint-mapping table, matching the v1alpha1 column's style (which never had /api/v1alpha1 in it) — shorter, more symmetric, and less prone to overflow in the first place. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replace the plain `GET /api/v2/user`-style inline code with the same .api-method / .api-path markup and color palette the hand-written v1alpha1 pages already use (see DocsLayout.astro) — GET teal, POST blue, PATCH/PUT orange, DELETE red. Repurposes the previously-unused methodBadge helper (a shields.io badge nobody called) into methodSpan. Regenerated database.md, operations.md, and user.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs: regenerate v2 API docs for the new SQL write endpoint
Move the method/path gap from .api-endpoint-header's flex `gap` (which only helped v1alpha1's card layout) onto .api-method's own margin-right, so the v2 pages' plain inline usage gets the same spacing without wrapping in .api-endpoint-header. Switch the badge text from white to a dark slate — the palette (teal, light blue, orange, red) is too light for white text to read clearly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.api-endpoint-header's square background fill wasn't clipped to the parent card's rounded corners, so the top corners looked cut off instead of rounded. Add overflow: hidden to the card. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
On narrow viewports, wide tables (5-column parameter tables, long unbroken paths) pushed past the content column instead of scrolling in place. Two cases, since the API docs mix real Markdown tables with raw HTML: - v2 pages' tables come from Markdown — add a rehype plugin (rehype-wrap-tables.mjs) that wraps every rendered <table> in a .table-scroll div with overflow-x-auto. - v1alpha1 pages hand-author <table class="api-params"> as raw HTML, which rehype-raw only expands into real nodes *after* our rehypePlugins run (@astrojs/markdown-remark's pipeline order), so the wrap plugin above can't see them. They're already nested inside .api-section / .api-response-body, so give those overflow-x: auto directly instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- .api-path had no way to break a long, space-less path (e.g.
/databases/{owner}/{database}/pulls/{pull_number}/comments),
so it overflowed its paragraph unconstrained and could blow out
the whole page horizontally on narrow viewports — the table
underneath just rode along with that page-level scroll. Add
overflow-wrap: anywhere + min-width: 0 (the latter for the
v1alpha1 flex-header case, where flex items default to
min-width: auto and ignore overflow-wrap otherwise).
- Giving .api-section overflow-x: auto (previous commit) forces
overflow-y to auto too (CSS requires both axes to leave
'visible' together), which establishes a block formatting
context and stops the child <h5>'s margin-top from collapsing
through into the visible gap the way it used to — v1alpha1's
.api-params tables lost their trailing space. Give .api-params
an explicit 1rem bottom margin instead of relying on collapse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Table cells like the Name column (\`owner\`, \`page_token\`, ...) and inline references in Description text (\`meta.next_page_token\`) are all <code> spans, which don't break without help. Even wrapped in .table-scroll, a table full of unbreakable code tokens still sizes itself to that unwrapped min-content width, forcing a wide scroll for tables that would otherwise fit fine. Add overflow-wrap: anywhere to code generally, so the browser's table auto-layout can actually shrink columns to the available width. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
overflow-wrap: anywhere also feeds into how browsers compute a table column's min-content width for auto-layout, so it let columns shrink far enough that even short words like "owner" or "Problem" no longer fit on one line and broke into single-letter orphans. break-word still wraps long tokens when a cell genuinely needs it, without telling the layout algorithm it's free to assume every word can split anywhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…active Auto layout gives each column exactly as much room as its content demands. For tables mixing several short columns (In/Type/Required) with a prose column (Description), that reliably exceeds a phone viewport — and every attempt to fix it by tuning how <code> wraps just traded one failure mode for another (mangled short words vs. page overflow), because the column widths were never the thing under control. Below 640px, switch to table-layout: fixed with a 4rem min-width per cell. Column widths are now deterministic: short cells (owner, yes, string) get guaranteed room to sit on one line, prose wraps normally, and only if the floors themselves can't all fit does the existing overflow-x: auto (.table-scroll / .api-section / .api-response-body) kick in as a fallback — scroll as a last resort, not the primary mechanism. Above 640px, untouched — auto layout already looked right there. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The card border ate into content width for no real benefit — the header's own background fill already separates it from the body, so the outer border was redundant framing. Keep the rounded corners and header separator, just lose the border (and the now-dead dark-mode border-color override that went with it). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Continues stripping unnecessary chrome from the v1alpha1 endpoint header now that the outer card border is gone too — the method badge and path text carry enough visual weight on their own. Also removes the now-dead dark-mode override for the fill/border that went with it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.api-endpoint-header, .api-summary, .api-description, and .api-section all had 1rem left/right padding inherited from when they sat inside a bordered card. Now that the border and header fill are gone, that padding was just an unexplained indent relative to the surrounding prose (headings, paragraphs) — drop it so this content sits flush left like everything else on the page. .api-response-body keeps its own left margin; that one's an intentional nesting indent (response body under its status line), not leftover card padding. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…badges # Conflicts: # site/dolt/src/content/products/dolthub/api/v2/database.md
docs: color-code v2 API method badges + responsive API endpoint tables
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.
No description provided.