 yuming
|
e9c7330f31
|
数据自愈迁移 + 后端同步幂等，版本号 v2.1.7 → v2.1.8
部署到群晖 / deploy (push) Successful in 57s
后端（server/src/index.js）——两处同步幂等：
1. deleteAnniversary 删除不存在的记录时返回 success:true。
原先返回 false，被前端 sync.js:34 当作失败重新入队，那条删除会永远留在
pending_sync_queue 里每次启动重试且永远清不掉。
2. updateAnniversary / updatePerson 在记录不存在时退化为插入（upsert）。
同一类问题：本地才是主真相源，若某条记录当初的 add 没同步成功，
之后所有 update 都会失败并无限重试。
前端 —— 新增 utils/migrate.js，在 app.js onLaunch 执行：
3. 补齐老数据缺失的农历字段。早期 lunar_birthday 类型只记公历日期，
没有 lunarMonth/lunarDay，这类记录会被安全降级成按公历算——不崩，但每年日期是错的。
用它存的公历日期反算回农历补齐。
4. 为孤儿纪念日重建人员。部分纪念日的 personId 指向已不存在的人（历史上删人没级联干净），
首页按 persons 遍历所以隐形，日历页按 anniversaries 遍历会显示成「未知」。
用记录自带的 personName 重建，并沿用原 personId，纪念日无需改动。
迁移放在客户端而非后端跑 SQL：本地 wx.Storage 是主真相源，改服务端会被客户端同步覆盖。
每次启动都跑而非记版本号：函数是纯检测式的，无坏数据时零写入零请求，
还能顺带覆盖「从云端拉回坏数据」的情况。顺便把原本是死代码的 initData() 替换掉。
⚠️ 本次后端有改动，需要重新部署；部署顺序应为先后端、后小程序。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-15 15:55:44 +08:00 |
|
|
yuming
|
ddcfe3334e
|
v2.1.0 流程改造 + 农历准确性修复 + 双向同步 + 闰月支持
部署到群晖 / deploy (push) Successful in 44s
- Phase 1: 添加纪念日合并人物创建流程（方案 B）
- Phase 2: 农历提醒按 lunarMonth/Day 计算每年公历
- Phase 3: 人员数据同步到后端（新增 /api/person）
- Phase 4: 新设备启动从云端恢复数据
- Phase 5: 工具函数收敛 utils/format.js
- Phase 6: 同步失败入队 + 启动重试
- Phase 7: 闰月生日完整支持（含 isLeapMonth + UI 警示）
- 修复 lunarInfo 数据表错位（替换为权威源 jjonline/calendar.js）
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-06-02 05:51:17 +08:00 |
|
|
yuming
|
3965e542fc
|
接入自建后端 + Gitea CI/CD
部署到群晖 / deploy (push) Failing after 6m22s
- 新增 server/：Node + Express + SQLite + node-cron 实现登录、纪念日 CRUD 和定时订阅消息推送
- 新增 .gitea/workflows/deploy.yml：推送即触发群晖 Docker 部署，监听 15002
- utils/api.js：自动按 envVersion 切换本地/线上 BASE_URL
- app.js 与 add-anniversary.js 移除 wx.cloud 调用，改走自建后端
- cloudfunctions/ 暂保留以便回滚
- 一并提交此前未入库的首页 / 设置页 / 日历 / 万年历等改造
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-06-01 15:44:09 +08:00 |
|
|
yuming
|
6747ade9c4
|
Initial Commit
|
2025-10-26 19:29:30 +08:00 |
|