삭제된 자소서의 문항 원문이 행 안에 그대로 남던 문제 - #226
Merged
Merged
Conversation
자소서 본문은 지원동기·성장과정 같은 지극히 개인적인 서술인데, 다른 자료와 달리 S3 가 아니라 행 안(cover_letters.items JSONB)에 산다. 그래서 #219 의 파기(원본 S3 객체 + 분석 마크다운 + 임베딩)가 자소서에는 절반만 적용됐다 — 분석물은 cascade 로 파기되지만 원문은 soft delete 된 행에 그대로 남는다. 삭제 후 items 를 읽는 곳은 없다. 목록·단건 조회는 deleted=false 필터가 있고, 분석은 생성 시점에 본문을 메시지 payload 에 인라인한다. 남길 이유가 없다. delete 가 같은 트랜잭션에서 items 를 빈 배열로 비운다. 컬럼이 NOT NULL DEFAULT '[]' 라 제약 변경이 필요 없다. V34 는 이 릴리스 전에 지운 자소서를 백필한다 — 삭제 이벤트가 다시 나지 않으므로 소급하지 않으면 영원히 남는다(V31·#223 과 같은 종류). 수정 전 코드에서 테스트가 실패하는 것을 확인했다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
문제 — #219 파기 체계의 마지막 구멍
자소서 도메인을 감사하다 나온 건이다. #219 는 자료 삭제 시 내용물을 파기한다 — 원본 S3 객체, 분석 마크다운, 임베딩 청크. 그런데 자소서는 원문이 S3 가 아니라 행 안에 산다 (
cover_letters.itemsJSONB — 문항별 질문·답변 텍스트).그래서 파기가 절반만 적용됐다:
자소서 본문은 지원동기·성장과정·갈등 경험 같은 지극히 개인적인 서술이다. 이력서 PDF 를 지우면 파기하면서 자소서 원문은 남긴다는 건 일관성이 없다.
삭제 후 아무도 읽지 않는다 — 확인했다
getItems()의 독자는 두 곳뿐이다:CoverLetterService.list—deleted=false필터AnalysisRequestService.requestCoverLetterAnalysis— 생성 시점에 본문을 마크다운으로 조립해 메시지 payload 에 인라인한다. 이후 콜백은analyzed_documents에만 쓴다즉 삭제된 행의
items는 참조 무결성에도, 어떤 기능에도 필요 없다.수정
delete()가 같은 트랜잭션에서items를 빈 배열로 비운다 (CoverLetter.purgeItems). 컬럼이NOT NULL DEFAULT '[]'라 제약 변경이 필요 없다 — V28·V32 때와 달리 CHECK 완화가 필요 없는 경우다테스트
delete_purgesInlineItemsAlongWithSoftDelete— soft delete 와 원문 파기가 함께 일어나는지. 수정 전 코드에서 실패하는 것을 확인했다.스코프 노트
title은 남긴다 — "OO 기업 공채 자소서" 수준의 라벨이라 문항 본문과 민감도가 다르고, 혹시 남는 참조(히스토리 표기 등)가 생겨도 무해하다. 원문 파기와 라벨 보존은 resumes 가original_filename을 남기는 것과 같은 결이다.