laoyang/FamilyBook
1
0
Fork 0
Code Issues 41 Pull Requests Actions Packages Projects Releases Wiki Activity

取消「票根」概念，并入观影照片（数据迁移 220 条）(#87)

Browse Source 
用户：现在不是已经没有票根的概念了吗？全部都换成观影照片了。别管是票根
还是观影照片，都在一起。现在只分两类：一类是海报，一类是观影照片。
海报是来自豆瓣的，这个不用管它，主要就是观影照片，所有的都在观影照片里边。

事实核查：概念取消了，数据没取消。网页端 v35 只在**模板层**把它们画进
同一个网格，数据层仍是两条路：票根在 movie_details.ticket_key（单张槽位），
不在 event_photos 里 ⇒ 没有 id ⇒ 删不掉，端上得写"票根另算"特判。

线上数据：有票根 220 条，其中 209 条只有票根、没有任何照片；
event_photos 总数才 14 —— 也就是说「观影照片」里装的几乎全是票根。

① 数据迁移（已执行，220/220 成功，失败 0）：
   逐条把 ticket_key 插进 event_photos（position 取比现有最小值再小 10，
   ⇒ 排第一，因为票根是"这场电影的凭证"，用户认知里排最前），然后置 NULL。
   event_photos 14 → 234，旧票根残留 0。
   ⚠️ 幂等：靠"该 key 已在该 event 的 event_photos 里"判断，重复跑不插重复行；
   ⚠️ 不删存储对象：只搬引用，图片原地不动，失败也不丢图。

② 同一段逻辑写进 Schema VERSION 36→37，让新库/重装库走同一套，
   不靠"记得手工跑脚本"。对线上是空操作（已验证 234→234）。

③ 服务端停止读写票根字段（字段保留作历史审计，代码不再碰）：
   - Movie::find 不再 SELECT ticket_key；
   - Movie::saveDetails UPSERT 去掉 ticket_key；
   - Movie::destroy 不再单独查/删票根对象（已并入 photos 循环）；
   - index.php：上传槽位 [poster,ticket] → [poster]，
     stage_ticket 不再认领，media_del 白名单只剩 poster；
   - form.php：删票根特殊格子 + mv-del-ticket 表单 + $mHasTicket；
   - show.php：删票根格子 + 灯箱 ticket 项 + $hasTicket。

验证：find(1,1)/find(1,224) 已不返回 ticket_key，photos 3/4 条票根在首位；
直接 include 模板无 Fatal，form.php 里 mv-del-ticket / stage_ticket 各 0 次；
6 个文件 md5 逐个核对一致、php -l 全过、已上线且升级到 37。
This commit is contained in:
laoyang
2026-11-06 11:25:47 +08:00
parent 94a557cd2e
commit 835f2846f2
5 changed files with 118 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files
app/Schema.php
+52 -1
View File
@@ -188,7 +188,7 @@ final class Schema
* ⚠️ 它**不再**作为"要不要跑升级"的判据 —— 见 fingerprint() 的说明。
* 它仍然要手工维护，因为它给人看（排查时一眼知道代码到哪一版了）。
*/
public const VERSION = '36';
public const VERSION = '37';
/**
* 「源码指纹」：拿**本文件自身的内容**算一个哈希，作为"要不要跑升级"的判据。
@@ -1887,6 +1887,57 @@ SQL);
self::addColumn($db, 'event_photos', 'mime',
"ADD COLUMN `mime` VARCHAR(100) DEFAULT NULL COMMENT 'MIME（视频转码后是 video/mp4；图片可空）' AFTER `thumb_key`");
// ---- 「票根」概念取消，并入观影照片（版本 37，2026-11-06）----
/* 🔴 用户原话：「现在不是已经没有票根的概念了吗？全部都换成观影照片了。
别管是票根还是观影照片，都在一起。现在只分两类：一类是海报，
一类是观影照片。海报是来自豆瓣的，这个不用管它，主要就是观影照片，
所有的都在观影照片里边。」
背景：早年「票根」是 `movie_details.ticket_key` 的**单张**槽位，
和 `event_photos`（现场照片）是两条并行的路径。v35 用户在网页端就说过
"不分类别，放一块"，但当时只在**模板层**把它画进同一个网格，
数据层仍然两条路 —— 结果是端上永远得写"票根另算"的特判，
而且票根没有 `event_photos` 行 id，**删不掉**。
这一版把数据也统一：
① 把每条记录的 `ticket_key` 插进 `event_photos`（position 排最前，
因为票根是"这场电影的凭证"，用户认知里它排第一）；
② `ticket_key` 置 NULL（字段保留，仅作历史审计，代码不再读写）。
⚠️ **幂等**：靠"该 key 是否已在该 event 的 event_photos 里"判断，
重复跑不会插重复行 —— 迁移在每次升级检查时都可能被调到。
⚠️ **不删存储对象**：只是搬引用，文件原地不动，失败也不会丢图。
⚠️ 2026-11-06 线上已手工跑过同一段逻辑（220 条全部搬完，
复核剩余旧票根=0、event_photos 234 条），所以这里对老库是空操作；
写进来是为了让**新库/重装库**走同一套，不靠"记得手工跑脚本"。 */
$tkRows = $db->query(
"SELECT event_id, ticket_key FROM movie_details
WHERE ticket_key IS NOT NULL AND ticket_key <> ''"
)->fetchAll();
if (count($tkRows) > 0) {
$hasPhoto = $db->prepare('SELECT COUNT(*) FROM event_photos WHERE event_id = ? AND `key` = ?');
$minPos = $db->prepare('SELECT COALESCE(MIN(position), 100) FROM event_photos WHERE event_id = ?');
$insPhoto = $db->prepare(
'INSERT INTO event_photos (event_id, `key`, position, kind, thumb_key, mime)
VALUES (?, ?, ?, ?, ?, ?)'
);
foreach ($tkRows as $tk) {
$eid = (int)$tk['event_id'];
$key = (string)$tk['ticket_key'];
$hasPhoto->execute([$eid, $key]);
if ((int)$hasPhoto->fetchColumn() > 0) {
continue;
}
$minPos->execute([$eid]);
$pos = max(0, (int)$minPos->fetchColumn() - 10);
$insPhoto->execute([$eid, $key, $pos, 'image', '', 'image/jpeg']);
}
/* 搬完清空旧槽位 —— 「只分两类」必须在数据层成立，
否则下一版又会有人写"票根另算"的特判。 */
$db->exec("UPDATE movie_details SET ticket_key = NULL
WHERE ticket_key IS NOT NULL AND ticket_key <> ''");
}
// ---- 纪念日（版本 13，用户第 13 条）----
// ⚠️ 名册里每个人的生日**不入这张表** —— 它们是实时从 persons 派生的
// （见 Anniversary::birthdays），改了生日纪念日就跟着变。