"target_date 를 바꾸는 건 같은 crumb 에 revision 을 append 하는 거야. 절대 tombstone 후 재생성 안 해."
crumb 를 잃지 않고 옮기기
바꿔도 되는 유일한 날짜는 target_date 야 — crumb 를 한 날에서 다른 날로 re-file 하거나, 다른 저널로 옮기거나, 텍스트를 고칠 수 있어. 질문은 어떻게 야. 게으른 답은 필드를 제자리에서 덮어쓰거나, 더 나쁘게는 crumb 를 지우고 새 날에 새로 만드는 거야. Vesta 는 둘 다 안 해. re-filing 은 append-only revision 이야. 이전 값과 revision 타임스탬프를 보존하는 CrumbRevision 레코드가 append 되고, crumb 의 ULID, captured_at, 타임존, 미디어 참조는 있던 그대로 남아. crumb 는 같은 crumb 야 — 배정만 옮겼고, 그 이동이 이제 그 history 의 일부야.
왜 삭제-후-재생성이 독이야
crumb 를 tombstone 하고 새로 만드는 건 동등해 보여 — 같은 텍스트, 새 날짜 — 근데 조용히 세 가지를 파괴해. 첫째, 정체성: 새 crumb 는 새 ULID 라서, 옛것을 가리키던 모든 게 이제 매달려 있어. 둘째, provenance: 원래 crumb 의 ID 를 source_crumb_ids 에 인용한 draft 가 갑자기 더는 존재하지 않는 crumb 를 참조하고, 문단의 lineage 가 깨져. 셋째, history: 이 조각이 원래 다른 날에 파일링됐다가 옮겨졌다는 기록이 사라져 — 마음을 바꿨다는 걸 더는 볼 수 없어. append-only revision 은 셋 다 보존하고, 삭제-후-재생성은 row 하나 아끼자고 셋 다 버려.
정체성은 날짜가 아니라 ULID 야
이게 되는 깊은 이유는 crumb 의 정체성이 태어날 때 고정된 ULID 지 어떤 가변 필드도 아니라서야. 날짜가 바뀌고, 저널이 바뀌고, 텍스트가 고쳐져도 — 그 전부를 관통해 ULID 가 절대 안 움직여서 같은 crumb 로 남아. 그게 draft 가 crumb 를 한 번 인용하고 그 인용을 영원히 믿게 하는 것 — crumb 가 두 번 re-file 된 뒤에도. 표현(어느 날, 어느 저널, 무슨 텍스트)은 유동적이고, 정체성은 기반암이야.