"target_date 를 바꾸는 건 같은 crumb 에 revision 을 덧붙이는 거야. 절대 지우고 새로 만들지 않아."
crumb 을 잃지 않고 옮기기
바꿔도 되는 유일한 날짜는 target_date 야. crumb 을 한 날에서 다른 날로 re-file 하거나, 다른 저널로 옮기거나, 텍스트를 고칠 수 있어. 질문은 어떻게냐지. 게으른 답은 칸을 제자리에서 덮어쓰거나, 더 나쁘게는 crumb 을 지우고 새 날에 새로 만드는 거야. Vesta 는 둘 다 안 해. re-filing 은 덧붙이는 revision 이야. CrumbRevision 하나가 이전 값과 시간을 남기며 붙고, crumb 의 ULID, captured_at, 타임존, 미디어 참조는 있던 그대로 남아. crumb 은 같은 crumb 이야. 배정만 옮겼고, 그 이동이 이제 그 history 의 일부가 돼.
왜 지우고 새로 만들기가 독이야
crumb 을 tombstone 하고 새로 만드는 건 같아 보여. 같은 텍스트, 새 날짜. 근데 조용히 세 가지를 부숴. 첫째, 정체성. 새 crumb 은 새 ULID 라 옛것을 가리키던 게 이제 허공을 가리켜. 둘째, provenance. 원본 crumb 의 ID 를 source_crumb_ids 에 인용한 draft 가 갑자기 없는 crumb 을 참조하고, 문단의 lineage 가 끊겨. 셋째, history. 이 조각이 원래 다른 날에 파일링됐다가 옮겨졌다는 기록이 사라져. 마음 바꾼 걸 더는 볼 수 없어. 덧붙이는 revision 은 셋 다 지키고, 지우고 새로 만들기는 row 하나 아끼자고 셋 다 버려.
정체성은 날짜가 아니라 ULID 야
이게 되는 깊은 이유는, crumb 의 정체성이 태어날 때 고정된 ULID 지 어떤 바뀌는 칸도 아니라서야. 날짜가 바뀌고 저널이 바뀌고 텍스트가 고쳐져도, 그 전부를 관통해 ULID 가 안 움직여서 같은 crumb 으로 남아. 그게 draft 가 crumb 을 한 번 인용하고 그 인용을 언제까지나 믿게 하는 거야. 그 crumb 이 두 번 re-file 된 뒤에도. 표현, 그러니까 어느 날인지 어느 저널인지 무슨 텍스트인지는 유동적이고, 정체성은 기반암이야.