aesthetic.computer
Monorepo for Aesthetic.Computer
aesthetic.computer
1# Lexicon Field Rename: mongoId → ref
2
3**Date:** 2025-10-14
4**Status:** ✅ Complete - Code Updated, Backward Compatible
5
6## Why the Change?
7
8The field name `mongoId` exposed implementation details (MongoDB database). Better naming:
9- **`ref`** - Generic reference to source database record
10- Doesn't expose what database we use
11- More professional and flexible
12
13## What Was Changed
14
15### 1. Lexicon Updated
16**File:** `/at/lexicons/computer/aesthetic/mood.json`
17
18```json
19{
20 "mongoId": { // OLD
21 "type": "string",
22 "description": "Reference to MongoDB _id (ObjectId as string) for bidirectional sync"
23 }
24}
25```
26
27↓
28
29```json
30{
31 "ref": { // NEW
32 "type": "string",
33 "description": "Reference to source database record for bidirectional sync"
34 }
35}
36```
37
38### 2. Code Updated
39
40**Files Modified:**
41- `/system/backend/mood-atproto.mjs` - All functions now use `refId` parameter
42- `/system/netlify/functions/mood.mjs` - Passes `refId` to ATProto sync
43- `/at/scripts/check-atproto-moods.mjs` - Shows "Database Ref" instead of "MongoDB ID"
44- `/at/scripts/check-atproto-duplicates.mjs` - Checks for duplicate `ref` values
45- `/system/backend/sync-mongodb-from-atproto.mjs` - Syncs using `ref` field
46- `/system/backend/delete-atproto-duplicates.mjs` - Identifies duplicates by `ref`
47
48### 3. Backward Compatibility
49
50**All scripts support BOTH old and new fields:**
51
52```javascript
53const ref = record.value.ref || record.value.mongoId; // Fallback to old field
54```
55
56This means:
57- ✅ Old @jeffrey moods with `mongoId` still work
58- ✅ New moods use `ref`
59- ✅ Scripts work with both
60- ✅ Gradual migration possible
61
62## Current State
63
64### Existing Data (@jeffrey)
65- 222 moods on ATProto with old `mongoId` field
66- 1 test mood with new `ref` field
67- All still functional due to fallback logic
68
69### New Data
70- All new moods created after this change use `ref`
71- Clean, implementation-agnostic naming
72
73## Migration Options
74
75### Option 1: Leave As-Is (Recommended)
76- Fallback logic handles both fields
77- No breaking changes
78- Old data still works
79- New data uses better naming
80- **Status:** ✅ This is what we're doing
81
82### Option 2: Re-migrate All Data
83- Would require deleting all ATProto moods
84- Re-creating them with `ref` instead of `mongoId`
85- More work, same end result
86- **Status:** ❌ Unnecessary due to fallback support
87
88## Code Examples
89
90### Creating a Mood (New Code)
91```javascript
92await createMoodOnAtproto(
93 database,
94 user.sub,
95 moodText,
96 new Date(),
97 refId // ← Clean, generic name
98);
99```
100
101### Reading ATProto Records (Backward Compatible)
102```javascript
103const ref = record.value.ref || record.value.mongoId; // Works with both!
104```
105
106## Testing
107
108Test the new `ref` field:
109```bash
110# Create a test mood (will use 'ref')
111cd /workspaces/aesthetic-computer/system
112node backend/test-create-mood.mjs jeffrey "Test with ref field"
113
114# Check it (supports both ref and mongoId)
115cd /workspaces/aesthetic-computer/at
116node scripts/check-atproto-moods.mjs jeffrey
117```
118
119## Summary
120
121✅ **Better naming** - `ref` instead of `mongoId`
122✅ **Backward compatible** - Old moods still work
123✅ **Future-proof** - Not tied to specific database
124✅ **All scripts updated** - Handle both fields
125✅ **No breaking changes** - Smooth transition
126
127---
128
129**Result:** Professional naming without breaking existing data! 🎉