Skip to content

Add namespaces so one database can hold separate contexts #26

Description

@himanshu231204

Problem

Every memory lands in one undifferentiated pile. Separate databases per project work today — --db ./project.db — but they're a blunt instrument: you lose cross-project recall entirely, and your general preferences don't follow you into a project.

What people actually want is one store with partitions: search this project, or search everything.

What to consider

A namespace column on memories, defaulting to something like "default", with a namespace argument on store and search. Tags can't do this job — they filter within one pile rather than partitioning it, and they don't give a sensible default scope for an agent that doesn't specify one.

Acceptance criteria

  • Namespace recorded per memory, with a sensible default
  • store_memory and search_memory accept a namespace; search can span all namespaces explicitly
  • Existing databases migrate cleanly — every current memory lands in the default namespace, and a release must open a database written by the previous version
  • CLI support, including listing namespaces and their counts
  • Tests: isolation between namespaces, cross-namespace search, migration from a pre-namespace database
  • Docs, including guidance on namespaces versus separate databases

Why this needs discussion first

This is the first change that touches the schema, which makes it the first real test of the migration story. It's worth getting the shape right before writing code.

Open questions:

  1. How does an agent know which namespace to use? If it must be told every call, it'll get it wrong. A server-level default via --namespace is probably necessary, with the tool argument as an override.
  2. Should search default to the current namespace or to everything? Defaulting to everything makes namespaces feel useless; defaulting to current makes an agent unable to find things it stored elsewhere without knowing to look.
  3. Does this overlap enough with per-database separation to not be worth it? A real argument — --db already works and adds no schema complexity. The case for namespaces rests mainly on cross-namespace search.

Please comment before building.

Pointers

  • src/localmem_mcp/store.py_SCHEMA, and the tag-filtering pattern in search() and recent()
  • RELEASE.md — what counts as a breaking schema change

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: storageSQLite schema, persistence, migrationsenhancementNew feature or requestneeds discussionDirection isn't settled — comment before buildingv0.4: contextsNamespaces, dedup, decay, compaction

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions