삭제하고 다시 만들면 연결이 끊긴다

외부에서 상품을 다시 가져올 때 옵션도 맞춰야 했고 가장 짧은 방법이 눈에 보였다. 기존 옵션을 전부 지우고 받은 대로 새로 만드는 방식이었다.

Open Table of contents

두 줄로 끝나는 방식

이 방식은 개수 차이와 순서 변경과 값 변경을 전부 한꺼번에 처리한다. 제자리 갱신은 기존 것과 짝을 맞추고 값을 고치고 개수 차이를 따로 다뤄야 해서 훨씬 길어진다.

코드 길이만 보면 비교가 안 될 만큼 짧은 쪽이 나아 보였다. 넣기 직전에 기존 옵션을 지우고 새로 만들면 안 된다는 제지를 받았다.

왜 안 되는지 보려고 옵션 모델을 열었더니 하위 관계가 여럿이었다. 재고와 채널별 판매가와 연동 정보가 각각 옵션 식별자를 외래키로 갖고 있었다.

옵션을 지우고 새로 만들면 식별자가 바뀌므로 셋 다 옛 식별자를 가리키게 된다. 옵션은 새로 생기지만 그 아래 매달려 있던 것들이 전부 갈 곳을 잃는다.

이 구조의 위험은 오류가 안 난다는 점이었다. 삽입은 성공하고 옵션 목록도 정상으로 보인다.

재고가 0으로 보이고 채널별 가격이 기본값으로 돌아가는 형태로 나중에 드러난다. 행위가 성공했다는 것과 의도한 상태가 됐다는 것이 갈리는 전형적인 자리였다.

기존 옵션을 유지하면서 값만 고치고 저쪽이 더 많으면 부족분만 추가하게 바꿨다. 식별자가 유지되므로 하위 관계가 그대로 남는다.

저쪽 개수가 더 적을 때도 남는 것을 지우지 않고 비활성 표시로 두었다. 지우는 순간 같은 문제가 다시 생기기 때문이다.

이 함정이 생기는 것은 작업 중인 테이블만 눈에 들어오기 때문이다. 옵션을 다루고 있으면 옵션을 가리키는 다른 테이블은 시야에 없다.

미리 알려면 그 모델의 외래키 컬럼 이름으로 코드를 훑어 가리키는 쪽을 찾는다. 모델의 관계 정의만 보면 역방향이 선언 안 된 것을 놓치므로 컬럼 이름으로 찾는 편이 확실하다.

이 규칙은 이 함수 하나가 아니라 옵션을 수정하는 모든 경로에 적용된다. 한 곳만 고치면 다른 경로에서 같은 일이 그대로 난다.