测验：用证据解释变更结果

승인 ID는 1·2·5, 감사 ID는 1·2·31이며 각각 세 건이다. 어떻게 보고해야 하는가?

• 세 건씩 맞으므로 전체 완료이며 ID 차이는 표현상의 차이로 처리한다.
• 승인 밖 31과 감사가 없는 5를 분리해 조사할 항목으로 남긴다.
• 현재 주문 수가 세 건이면 승인 목록을 감사 ID로 덮어써 일치시킨다.
• 31을 5로 자동 변환하면 보고 건수를 유지하면서 문제를 해결할 수 있다.

기본 Read Committed에서 BEGIN 뒤 승인·감사·현재 행을 순서대로 SELECT했다. 무엇을 주의해야 하는가?

• 같은 연결의 조회이므로 다른 연결의 커밋은 어떤 경우에도 보이지 않는다.
• SELECT가 여러 번이면 데이터가 자동 잠겨 모든 업무 변경이 차단된다.
• BEGIN만 있으면 세 쿼리는 항상 첫 번째 조회 순간의 값을 반환한다.
• 다른 연결이 중간에 커밋하면 문장마다 다른 시점의 자료가 섞일 수 있다.

감사는 승인과 정확히 맞지만 현재 행의 revision이 감사의 이후 revision보다 크다. 이번 분류는?

• 과거 확정은 인정하되 현재는 후속 차이로 분리하고 완료 주장을 보류한다.
• 현재 상태 문자열만 cancelled이면 revision 차이를 무시하고 일치로 센다.
• 과거 확정 자체가 없었던 것으로 간주해 감사와 승인 ID를 모두 삭제한다.
• 보고서 생성 중 현재 revision을 감사 값으로 낮춰 원래 상태를 만든다.

누군가 보고 판정을 complete로 바꾸고 해시도 다시 계산했다. 필요한 검사는?

• 해시가 새 내용과 맞으면 변경 승인과 실행 근거를 보지 않아도 된다.
• 파일 크기가 원본과 비슷하면 문장 편집으로 보고 그대로 허용한다.
• 원 증거에서 기계 판정과 고객 설명을 다시 계산해 번들과 비교한다.
• UTC 시각이 있으면 작성자를 인증한 것이므로 판정을 신뢰할 수 있다.

완성 바이트를 임시 파일에 썼지만 os.replace 전에 예외가 났다. 요구한 결과는?

• 보고가 시작됐으므로 이전 파일을 지우고 빈 파일을 최종 결과로 남긴다.
• 기존 완성본을 보존하고 이번 호출이 만든 임시 파일만 정리한다.
• 이전 파일을 새 파일 앞에 붙여 두 보고서의 내용을 모두 유지한다.
• 실패한 파일을 정상 이름으로 바꾸고 사용자가 다시 읽게 한다.

저장된 보고서의 해시와 내부 대조가 모두 통과했다. 어떤 주장을 할 수 있는가?

• DB가 지금도 같은 상태이고 보고서를 만든 사람이 정당한 담당자임을 증명했다.
• 관측 시각을 공격자가 바꿀 수 없으므로 별도 수집 경로 확인은 필요 없다.
• 전체 고객 시스템의 상태가 동시에 수집됐으므로 외부 API도 검증됐다.
• 이 형식의 바이트·증거·결론이 내부적으로 맞지만 현재 상태나 출처 인증은 별도다.