Skip to content
isdnetworks
Go back

소유를 가르는 값

우리가 만든 자료와 고객이 올린 자료가 한 테이블에 있었고 이름 앞에 붙인 접두어로 구분하고 있었다. 고객이 이름을 바꿀 수 있다는 것이 이 구분의 전제를 무너뜨렸다.

Table of contents

Open Table of contents

이름 규칙이 가르던 소유

우리가 만든 것에는 정해진 접두어를 붙이고 조회할 때 그 패턴으로 갈랐다. 접두어가 있으면 시스템 자료이고 없으면 고객 자료라는 규칙이었다.

이 규칙은 이름이 안 바뀐다는 전제 위에 서 있었다. 그런데 이름은 고객이 언제든 바꿀 수 있는 값이었다.

이름을 바꾸면 구분이 깨진다

고객이 그 접두어로 시작하는 이름을 지으면 그 자료가 시스템 것으로 잡힌다. 반대로 우리 자료의 이름이 바뀌면 고객 것으로 잡힌다.

두 방향 모두 조용히 어긋나고 어디서도 오류가 나지 않는다. 구분의 근거가 사용자가 바꿀 수 있는 값이면 그 구분은 언젠가 깨진다.

값으로 옮긴 뒤의 조건

소유 유형 컬럼을 두고 기존 이름 규칙으로 한 번 채운 뒤부터는 그 값으로 갈랐다. 이름을 바꿔도 구분이 유지되므로 이름 규칙 자체를 없앨 수 있었다.

소유에 따라 수정 권한과 삭제 가능 여부와 갱신 시 덮기와 백업 대상과 과금이 갈렸다. 전에는 이름 비교가 코드 여기저기에 흩어져 있었는데 값 하나로 판단하니 조건이 한 자리에 모였다.

덮는 범위와 이름 삭제의 위험

시스템 자료는 판을 올릴 때 지우고 다시 넣는데 전에는 그 삭제를 이름으로 했다. 고객이 그 접두어로 시작하는 이름을 지었으면 갱신 때 같이 지워진다.

실제로 고객 자료 몇 개가 그렇게 사라진 적이 있었다. 소유 값으로 지우게 바꾸니 남의 것이 딸려 갈 자리가 없어졌다.

둘로 안 나뉘는 중간 성격

우리가 준 기본 서식을 고객이 고쳐 쓰는 것이 있었는데 덮으면 고친 내용이 사라진다. 그래서 시스템과 고객 사이에 고객이 수정한 시스템 자료라는 유형을 하나 더 뒀다.

고객이 고치는 순간 유형이 바뀌고 그 뒤로는 덮지 않는다. 갱신할 때 건너뛴 것을 목록으로 알려서 새 판을 원하면 개별로 처리하게 했고 같은 문제가 있던 설정과 알림 규칙과 계정에도 같은 값을 넣었다.

정리


Share this post on:

Previous Post
저장소가 아니었던 도메인
Next Post
200이 성공을 뜻하지 않는다