Rename knowledge schema to memory; config reads DATABASE_URL - #32
Merged
Conversation
Pre-GA safe rename: no deployment has run migrations against the `knowledge` schema yet, so this is a clean cutover with no back-compat concerns. Postgres schema is now `memory`, table/type identifiers (memoryDocument, MemoryEdgeHint, etc) follow suit, and loadMemoryConfig reads DATABASE_URL instead of KNOWLEDGE_DATABASE_URL. Baseline migration edited in place and renamed to 0002_memory_baseline.sql since it has never run in production.
5 tasks
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
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.
Summary
CL-6009 phase 1: renames the package's Postgres schema from
knowledgetomemory, and switches config to readDATABASE_URLinstead ofKNOWLEDGE_DATABASE_URL.This is a safe pre-GA rename: no deployment has ever run migrations
against the
knowledgeschema, so there is no back-compat or migrationconcern — the baseline migration SQL is edited in place rather than layered
with a new migration.
knowledge→memory(MEMORY_SCHEMA,memorySchemainsrc/db/schema.ts)knowledgeDocument→memoryDocument,knowledgeVersion→memoryVersion,knowledgeChunk→memoryChunk,knowledgeEntity→memoryEntity,knowledgeEdge→memoryEdge,knowledgeEmbedModel→memoryEmbedModelKnowledgeDocumentSchema→
MemoryDocumentSchema,KnowledgeVersion*→MemoryVersion*,KnowledgeChunk*→MemoryChunk*,KnowledgeEntity*→MemoryEntity*,KnowledgeEdge*→MemoryEdge*loadMemoryConfig()now readsDATABASE_URL(hard cutover, no fallback tothe old var name)
0002_knowledge_baseline.sqledited in place andrenamed to
0002_memory_baseline.sql(migrations are discovered/orderedby filename prefix, so the rename is safe);
0001_extensions.sql'sCREATE SCHEMAstatement updated toodocs/AUTHZ-DOCUMENT-ACCESS.md),
.env.example, andcompose.ymlupdatedto match
schema/identifier rename) was left alone
Test plan
bun run typecheck— passesbun test ./src— 320 pass / 0 fail (fully mocked, no live Postgresrequired for this suite)