JDSS/mem0
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: cleanup docs with stale contents

Browse Source
This commit is contained in:
agumpandey
2026-05-05 18:23:30 +05:30
parent 91033fc0e9
commit b2d2c8a8ef
6 changed files with 13 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/migration/oss-to-platform.mdx
+6 -10
View File
@@ -72,13 +72,13 @@ client = MemoryClient(api_key="m0-...")
```
<Info icon="check">
Run `client.get_all(filters={"user_id": "test_connection"}, page=1, page_size=1)` to verify your API key works. A healthy response is a paginated envelope like `{"count": 0, "next": null, "previous": null, "results": []}` or the same shape with results.
Run `client.get_all(filters={"user_id": "test_connection"})` to verify your API key works. It should return an empty list or valid results.
</Info>
### 3. Update Retrieval Calls (Critical)
<Warning>
**Critical Change**: Platform uses V3 endpoints and requires entity filters to be nested inside a `filters` dictionary.
**Critical Change**: Platform uses v2 endpoints that require filtering parameters to be nested inside a `filters` dictionary.
</Warning>
<Note>
@@ -95,10 +95,6 @@ client = MemoryClient(api_key="m0-...")
Note: `add()` and `delete()` methods remain unchanged. The `update()` method is not available in Platform - use delete + add pattern instead.
<Note>
Platform search stays compatible with the normal `results[]` shape, but V3 may include additional top-level fields such as `score_breakdown`, `memory_type`, `event_date`, and `effective_plan_status` when the platform has structured context for the result.
</Note>
<AccordionGroup>
<Accordion title="Search Memories">
<CodeGroup>
@@ -136,11 +132,11 @@ Note: `add()` and `delete()` methods remain unchanged. The `update()` method is
```
```python Platform (New)
# Get the first page of memories for a user
page = client.get_all(filters={"user_id": "alex"}, page=1, page_size=10)
# Get all memories for a user
memories = client.get_all(filters={"user_id": "alex"}, top_k=10)
# Get the next page
next_page = client.get_all(filters={"user_id": "alex"}, page=2, page_size=10)
# Get memories with pagination
memories = client.get_all(filters={"user_id": "alex"}, top_k=5, offset=10)
```
</CodeGroup>
</Accordion>
docs/migration/platform-v2-to-v3.mdx
+1
View File
@@ -307,6 +307,7 @@ If your application previously read graph relations from the API response (`rela
- **V1 and V2 endpoints continue to work.** There is no requirement to migrate to V3 endpoints immediately.
- **Existing memories are preserved.** The new algorithm does not modify or re-process previously stored memories.
- **Search response shape is unchanged.** The top-level `score` and `results[]` array are the same; existing code that reads `score` continues to work. What changed is the scoring method behind the number (multi-signal fusion instead of pure cosine), so the absolute values shift even when ranking stays comparable.
- **Search remains backward-compatible at the top level.** Existing code that reads `results[]` and `score` continues to work, but V3 can now include extra top-level result fields such as `score_breakdown`, `memory_type`, and temporal fields when available.
- **List response shape changed.** `get_all` now returns a paginated envelope (`{count, next, previous, results}`) instead of a bare `{results: [...]}`. Update code that reads `response["results"]` to continue working, or switch to the client SDKs which handle both shapes.