Skip to content

docs(meta/design): clarify DB-backed devtools source storage#8715

Merged
hyf0 merged 2 commits into03-13-docs_meta_design_add_devtools.md_from
copilot/sub-pr-8663
Mar 15, 2026
Merged

docs(meta/design): clarify DB-backed devtools source storage#8715
hyf0 merged 2 commits into03-13-docs_meta_design_add_devtools.md_from
copilot/sub-pr-8663

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Mar 15, 2026

The devtools design doc now makes the intended database storage model explicit: large source-like payloads should be stored once and referenced by ID, rather than duplicated across hook and asset records. This tightens the future-backend guidance in the section describing a database-backed devtools store.

  • Schema sketch

    • Replaced the generic hook_call_content example with a dedicated sources(source_id, content) table.
    • Updated hook_calls and assets to reference payloads via input_source_id, output_source_id, and content_source_id.
  • Storage model

    • Clarified that database-backed storage should keep source/code payloads in standalone rows/fields and reference them from action records by ID.
    • Kept the comparison to the current StringRef approach, but framed it as relational deduplication with queryable references.
  • Illustrative shape

    sources(source_id, content)
    hook_calls(..., input_source_id, output_source_id)
    assets(..., content_source_id)
    

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.

Co-authored-by: hyf0 <49502170+hyf0@users.noreply.github.com>
Copilot AI changed the title [WIP] Add historical context about devtools docs(meta/design): clarify DB-backed devtools source storage Mar 15, 2026
Copilot AI requested a review from hyf0 March 15, 2026 15:42
Copilot finished work on behalf of hyf0 March 15, 2026 15:42
@hyf0 hyf0 marked this pull request as ready for review March 15, 2026 15:46
Copilot AI review requested due to automatic review settings March 15, 2026 15:46
@hyf0 hyf0 merged commit fae3744 into 03-13-docs_meta_design_add_devtools.md_ Mar 15, 2026
2 checks passed
@hyf0 hyf0 deleted the copilot/sub-pr-8663 branch March 15, 2026 15:46
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the devtools design document to make the intended database-backed storage model explicit: large source-like payloads should be stored once and referenced by ID from hook/action records, aligning the future DB approach with the current StringRef dedup concept.

Changes:

  • Replaced the hook_call_content sketch with a dedicated sources(source_id, content) table for large payload storage.
  • Updated the hook_calls and assets schema examples to reference payloads via *_source_id fields.
  • Clarified in prose that DB-backed backends should avoid inlining large payloads into action rows and instead reference standalone content rows.

You can also share your feedback on Copilot code review. Take the survey.

hook_calls(build_id, call_id, hook_type, plugin_name, plugin_id, module_id, started_at, ended_at)
hook_call_content(call_id, content_before, content_after) -- large text in separate table
assets(build_id, filename, chunk_id, size)
sources(source_id, content) -- store large payloads/source text once
Comment on lines +236 to +240
hook_calls(build_id, call_id, hook_type, plugin_name, plugin_id, module_id, started_at, ended_at, input_source_id, output_source_id)
assets(build_id, filename, chunk_id, size, content_source_id)
```

Separating large content (`hook_call_content`) from metadata (`hook_calls`) means consumers querying plugin timing never touch the multi-GB source text. This is the relational equivalent of the current `StringRef` dedup pattern, but with proper query support.
Separating large content from metadata means consumers querying plugin timing never touch the multi-GB source text. For a database-backed design specifically, source-like payloads should live in standalone fields/rows (for example, `sources.content`) and actions should reference them by ID (`input_source_id`, `output_source_id`, `content_source_id`) instead of inlining the same source everywhere. This is the relational equivalent of the current `StringRef` dedup pattern, but with proper query support.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants