测验：获批的两笔订单不是任意两笔订单

아침에 승인받은 대기 주문은 2건입니다. 오후에도 대기 주문이 2건이면 그대로 취소해도 되나요?

• 아니다. 고객·ID·버전·수량이 승인 내용과 같은지 확인한다
• 그렇다. 건수가 같으면 변경의 영향 범위도 같다고 본다
• 그렇다. 같은 WHERE 조건을 사용했다면 새 주문도 승인된 것이다
• 아니다. 새 주문을 포함하도록 기존 승인 목록을 자동 갱신한다

승인 때 qty=7, revision=3이었고 지금 qty=7, revision=5입니다. 이 실습의 올바른 판단은?

• 수량이 같으므로 승인한 사실이 그대로라고 판단한다
• 버전이 달라졌으므로 현재 사실을 다시 확인하고 승인을 검토한다
• revision을 3으로 되돌리고 기존 승인을 그대로 실행한다
• 수량이 같으므로 나머지 고객 조건은 생략하고 처리한다

승인 목록에 같은 주문 ID가 두 번 들어 있습니다. 검증기는 어떻게 처리하나요?

• 같은 주문을 두 번 취소하고 두 번의 변경으로 센다
• 마지막 항목만 남겨 입력 충돌을 조용히 해결한다
• 중복 대상을 ValueError로 거부하고 입력을 보존한다
• 첫 항목을 적용한 뒤 두 번째 항목의 실패만 무시한다

validate_targets가 새 list를 만들었지만 내부 dict는 입력과 공유합니다. 어떤 문제가 남나요?

• ID 정렬이 반드시 역순이 되어 SQL 문법 오류가 난다
• PostgreSQL이 같은 객체 주소를 보고 요청을 중복 제거한다
• 반환 목록이 비어 있지 않으므로 검증의 의미가 없어진다
• 반환 항목을 수정한 코드가 원래 승인 입력까지 바꿀 수 있다

왜 주문 번호 True를 정수 1처럼 받아들이지 않나요?

• 논리값이 번호로 해석되는 승인 입력 오류를 막기 위해서다
• PostgreSQL의 모든 정수 열이 1을 금지하기 때문이다
• Python에서 True는 언제나 문자열로 저장되기 때문이다
• 동일한 주문의 재시도는 반드시 다른 번호여야 하기 때문이다

함수에 tenant='blue'를 전달하면 호출자의 blue 고객 데이터 변경 권한도 검증되나요?

• 그렇다. 문자열이 SQL 조건에 들어가면 로그인 검증도 수행된다
• 아니다. 고객 범위 조건과 호출자의 권한 검증은 별도 책임이다
• 그렇다. 변경 ID가 고유하면 모든 고객의 데이터를 바꿀 수 있다
• 아니다. 권한 검증을 위해 tenant 조건은 UPDATE에서 빼야 한다