Skip to content

feat: support custom memory types via MemoryType::Custom(String)#79

Open
allengaoo wants to merge 1 commit intomatrixorigin:mainfrom
allengaoo:feat/custom-memory-type
Open

feat: support custom memory types via MemoryType::Custom(String)#79
allengaoo wants to merge 1 commit intomatrixorigin:mainfrom
allengaoo:feat/custom-memory-type

Conversation

@allengaoo
Copy link
Copy Markdown

@allengaoo allengaoo commented Mar 21, 2026

Summary

  • Add Custom(String) variant to MemoryType enum, allowing downstream applications to define domain-specific memory categories (e.g. brand_theme, layout_catalog, writing_style) without modifying Memoria source code
  • Make FromStr infallible — unrecognized strings are accepted as Custom(name) instead of returning InvalidMemoryType error (HTTP 422)
  • Widen memory_type DB column from VARCHAR(20) to VARCHAR(64) to accommodate longer custom type names

Motivation

When integrating Memoria into a PPT generation agent, we needed domain-specific memory types (brand_theme, layout_catalog, writing_style, component_pattern) to store structured knowledge extracted from PowerPoint templates and style profiles. The current hardcoded 6-variant enum rejected these types with HTTP 422, forcing all custom semantics to be shoehorned into generic types like profile or semantic, which breaks type-filtered retrieval.

Changes

File Change
memoria-core/src/types.rs Add Custom(String) variant, hand-implement Serialize/Deserialize for flat JSON representation, make FromStr return Infallible, add is_builtin() helper
memoria-storage/src/store.rs VARCHAR(20) → VARCHAR(64), update row_to_memory to use infallible parse
memoria-api/src/models.rs Simplify parse_memory_type (now infallible)
memoria-api/src/routes/governance.rs Update to infallible parse, remove unused import
memoria-mcp/src/tools.rs Update two call sites to infallible parse

Backward Compatibility

  • All 6 built-in types (semantic, working, episodic, profile, tool_result, procedural) parse to their original enum variants — zero behavioral change for existing data
  • InvalidMemoryType error variant is retained in MemoriaError for backward compat but is no longer produced by FromStr
  • JSON serialization format is unchanged for built-in types (flat strings)
  • Custom types serialize as flat strings (e.g. "brand_theme", not {"Custom":"brand_theme"})
  • VARCHAR(64) is backward compatible with existing VARCHAR(20) data

Test plan

  • cargo test -p memoria-core — all 12 tests pass including new test_custom_type_roundtrip and test_custom_type_serde_roundtrip
  • cargo build --release — zero warnings
  • Manual API validation: POST /v1/memories with memory_type: "brand_theme" returns 200 (previously 422)
  • Manual retrieval validation: POST /v1/memories/retrieve with memory_types: ["brand_theme"] returns filtered results

The built-in MemoryType enum (6 variants) was too restrictive for
downstream applications that need domain-specific memory categories
(e.g. `brand_theme`, `layout_catalog`, `writing_style`).

Previously, any unrecognized memory_type string sent to the REST API
was rejected with HTTP 422, forcing every integration to shoehorn
their semantics into the 6 built-in types.

Changes:
- Add `Custom(String)` variant to `MemoryType` enum
- Make `FromStr` infallible — unknown strings become `Custom(name)`
- Hand-implement `Serialize`/`Deserialize` to preserve flat string
  representation in JSON (e.g. `"brand_theme"`, not `{"Custom":"brand_theme"}`)
- Widen `memory_type` column from `VARCHAR(20)` to `VARCHAR(64)` to
  accommodate longer custom type names
- Add `is_builtin()` helper method
- Update all call sites to use infallible `.parse::<MemoryType>().unwrap()`
- Add tests for custom type roundtrip and serde
@aptend aptend requested a review from XuPeng-SH March 24, 2026 08:41
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.

1 participant