<aside> 💡 #unique #handle #slug #localhost #allauth #s3 #cors #status_code
</aside>
저는 책을 쓰면서 동시에 진행한 토이 프로젝트 Allbooks를 구현하는 과정에서 발생한 다양한 에러상황을 트래킹 하고 있습니다. 깃허브 이슈를 통해서 문제를 공론화 하고 적극적인 토론을 지향하는 문화를 만들고 싶습니다.
https://github.com/ESTsoft-Book-Project/bookstore/issues/41
pk를 사용하지 않고 핸들을 사용하여 리소스를 식별하자고 결정한 이래로 발생한 문제입니다. 추가 의존성으로 slugify를 채택했는데, 이름이 같으면 핸들이 같아지는 상황이 발생해 IntegrityError가 발생합니다. 따라서 해당 문제를 해결하기 위해 이슈를 생성했습니다.
제일 먼저 나온 방식은 반복문을 돌면서 핸들 뒤에 중복되지 않는 고유한 숫자를 찾는 것입니다. 이는 제품의 이름을 변경할 때에도 적용이 됩니다.
문제는 위의 방식에 따르면, 같은 이름의 상품이 N개가 존재한다면 고유한 숫자를 찾기 위해 최대 N번의 검사가 필요합니다. 따라서 더 효율적으로 고유한 값을 찾을 필요가 있습니다.
팀원 중 한 명이 핸들 뒤에 상품의 PK를 넣는게 어떻겠느냐는 제안을 했습니다. 이 방식은 한 번 생성된 상품을 삭제하더라도 다시는 해당 PK 번호를 사용하지 않는다는 점이 좋았습니다.
하지만 객체를 저장하기 전까진 PK가 존재하지 않는다는 점이 있었습니다. 그렇다고 PK를 알기 위해 느린 save를 두 번이나 할 수는 없었습니다.
UUID를 사용하는 방법도 제안됐습니다. 슬러그의 길이가 길어진다는 단점(16자리)이 있지만 표준에 근거한 고유한 슬러그를 만들 수 있다는 장점이 있습니다. 파이썬 내장 모듈인 uuid는 uuid1(), uuid3(), uuid4(), uuid5()라는 네 가지 함수가 있고, 각각 다른 방식으로 uuid를 생성해 준다고 합니다.
Product.objects.order_by(“id”).last()+1다음 stackoverflow 대화(https://stackoverflow.com/a/48428923/6428901)에서 괜찮은 아이디어를 얻었습니다. 바로 모델의 마지막 id를 찾아내는 것입니다. 앞서 설명했듯이 PK는 한 번 결번이 되면 다시는 사용하지 않는다는 특성이 있습니다. 따라서 마지막으로 생성된 객체의 id는 전체 id중 항상 가장 큰 값을 가지게 될 것입니다.
이 방법은 드물지만 Race Condition에 고유성 원칙을 위반할 여지가 있다고 합니다. 따라서 높은 일관성을 필요로 하는 서비스에서는 적합하지 않을 것입니다.
https://github.com/ESTsoft-Book-Project/bookstore/issues/63
localhost와 127.0.0.1은 동일하지 않다.