refactor(adapter-sqlite): drop redundant attachments table#40
Merged
Conversation
The adapter interface previously accepted only raw bytes, forcing callers to omit Content-Type and Content-Disposition on upload. Now putAttachment accepts optional mimeType and filename params: APIAdapter forwards them as HTTP headers (defaulting to application/octet-stream), while the SQLite and test adapters accept but ignore them since they store locally. Stack.putAttachmentBytes / Stack.putAttachment / ScopedStack.putAttachment all forward the params so the metadata that was already tracked in the _attachment@1 record is also reflected in the binary upload request. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqkRy1ZDZqL6JDW9Xod5UX
…ource of truth The attachments table was stripped to just (file_id TEXT PRIMARY KEY) when _attachment@1 records took over metadata tracking. With content-addressed storage the filesystem already deduplicates by SHA-256 filename, making the table a redundant shadow of the disk. - Remove attachments table from SCHEMA_SQL - runMigrations: drop the table if still present in older databases - putAttachment: dedup via existsSync instead of SELECT 1 - getAttachment: existence check via existsSync (no DB query) - deleteAttachment: remove DELETE FROM attachments (only unlink needed) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqkRy1ZDZqL6JDW9Xod5UX
…ilename params The adapter layer is a raw bytes store — metadata belongs exclusively on _attachment@1 records created by Stack/ScopedStack.putAttachment. Passing mimeType and filename through the adapter interface leaked HTTP/semantic concerns into a layer that has no use for them (SQLite accepted but ignored them). The Stack layer already captures the right metadata at the right level. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RqkRy1ZDZqL6JDW9Xod5UX
cuibonobo
changed the title
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
2 participants
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.
The
attachmentstable in the SQLite adapter was originally the home for attachment metadata (mimeType, size, filename, created_at). When the_attachment@1PR moved that metadata into records, the table was stripped to just(file_id TEXT PRIMARY KEY)— a SQLite-backed shadow of what's already on disk.Since binary files are content-addressed by their SHA-256 hash, the filesystem is already the authoritative store. The table added no information and required its own migration path.
Changes
adapter-sqlite: Remove theattachmentstable fromSCHEMA_SQL;runMigrationsnow drops the table if still present in older databases. ReplaceSELECT 1 FROM attachmentsdedup/existence checks withexistsSync; removeINSERT/DELETEqueries and the now-unnecessarypersist()calls from attachment methods.What didn't change
StackAdapter.putAttachmentremains bytes-only — no mimeType or filename params at the adapter level. Metadata belongs exclusively on_attachment@1records created byStack/ScopedStack.putAttachment.