86 lines
2.9 KiB
Markdown
86 lines
2.9 KiB
Markdown
# 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
|