2.9 KiB
Phase 16: Multi-User Data Model - Discussion Log
Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
Date: 2026-04-05 Phase: 16-multi-user-data-model Areas discussed: User ID Representation, Existing Data Migration, Category Uniqueness, Settings Scope, API Key Ownership Mode: --auto --batch (all decisions auto-selected)
User ID Representation
| Option | Description | Selected |
|---|---|---|
| Local users table with integer ID | Thin table mapping Logto sub to auto-increment integer, all FKs use integer | ✓ |
| Logto sub string directly | Store Logto sub (string UUID) as FK on every entity table | |
| Mapping table without FK | Store logtoSub on entities, join manually |
User's choice: Local users table with integer ID (auto-selected) Notes: Integer FKs are more efficient for joins. Thin table auto-creates on first OIDC login.
Existing Data Migration
| Option | Description | Selected |
|---|---|---|
| Migration assigns all rows to user ID 1 | Add userId column, set all existing data to first user | ✓ |
| Prompt for Logto sub during migration | Interactive script asks for the Logto user ID | |
| Leave data unassigned until claimed | Nullable userId, user claims data on first login |
User's choice: Migration assigns all rows to user ID 1 (auto-selected) Notes: Single existing user, simplest approach.
Category Uniqueness
| Option | Description | Selected |
|---|---|---|
| Composite unique (userId, name) | Each user has independent category namespace | ✓ |
| Global unique (current) | All users share one category namespace |
User's choice: Composite unique (userId, name) (auto-selected) Notes: Required by MULTI-03.
Settings Scope
| Option | Description | Selected |
|---|---|---|
| Composite PK (userId, key) | Each user has own settings | ✓ |
| Separate user_settings table | New table for per-user settings |
User's choice: Composite PK (userId, key) (auto-selected) Notes: Required by MULTI-06. Minimal schema change.
API Key Ownership
| Option | Description | Selected |
|---|---|---|
| userId column on apiKeys | API keys belong to creating user, middleware resolves user scope | ✓ |
| Shared API keys (no user scope) | API keys grant access to all data |
User's choice: userId column on apiKeys (auto-selected) Notes: Required by MULTI-05 for MCP tool scoping.
Claude's Discretion
- Migration SQL approach
- userId scoping helper vs inline where clauses
- Default category creation strategy
- Thread resolution cross-user checks
- Service change ordering
Deferred Ideas
None — discussion stayed within phase scope