티스토리 뷰
개요
앞선 글(언제나 복잡한 이름 순 정렬 구현하기)에 이어서 파일 드라이브의 정책 관련 이야기들 중 하나다. 별로 재미없는 이야기인데, 내가 했던 고민들을 정리해보려고 한다.
현재 개발 중인 서비스에 파일을 관리할 때 파일들이 고유한 id를 갖게끔 구성했다. 그래서 순도 100% 백엔드 개발자 마인드로 어차피 id로 구분되니까 파일 이름이 중복되도 문제가 없지 않을까...? 란 생각을 했지만... 다른 팀원들의 생각은 달랐다. 그 결과 나는 반대했지만 결국 중복된 이름 생성을 방지하기 위한 다양한 정책이 나오기 시작했다...
어떤 문제가 있었고 이에 따른 어떤 정책들이 있었으며 어떻게 처리했는지 하나씩 알아보자.
1. 생성 시 동일한 이름이 있다면 어떻게 해야하나?
이건 정책적으로 그냥 막기로 했다. 그래서 별다른 이슈가 없이 넘어갔고...
2. 복사했을 때
드라이브를 개발하면서 예시로 많이 사용했던게 구글 드라이브와 윈도우인데, 구글 드라이브의 경우는 중복을 허용한다. 윈도우의 경우는 (1), (2) 라는 suffix(접미사)가 붙는다. 그래서 윈도우를 따라가자고 했는데... 여기서도 몇 가지 예외가 나오게 된다. 이거에 대한 답을 정리해보면... 다음과 같다
1. 동일한 이름을 갖지만 파일 이름 뒤에 (10) 이 있으면 어떻게 할까?
aaa (10) (1) 이런식으로 붙인다.
2. (1) (3) (5) 이렇게 중간 중간 비면 또 어떻게 할까?
서로 다른 파일이다. aaa (1) (1), aaa (3) (1), aaa (5) (1) 이렇게 따로 따로 시작한다.
3. 이미 (1)을 갖는 파일은 어떻게 suffix를 만들까?
aaa (1) (1) 이런식으로 붙인다.
4. suffix를 붙이다가 글자 수를 넘어가는 글자 수 제한을 넘어가는 경우는?
글자 수 초과 메시지를 띄운다
3. 이동했을 때
이것도 정책적으로 적용했다. 이동하려는 위치에 같은 이름의 파일이 있음을 알려주고(팝업이나 알림을 줌), 덮어 쓰기 진행. 기존 파일은 삭제한다.
4. 휴지통에서 복원했을 때
복원했을 때, _recovery를 붙임. 복원 위치에 _recovery가 붙은 이름이 있으면 _recovery (1)로 이름을 지정. 복원 위치가 이미 삭제되어 없다면 루트 파일 아래에 최상단 경로로 이동시킨다.
5. 그렇다면 suffix에 (d+) 을 어떻게 붙일까?
동일한 경로에 (1) 이 붙은 파일이 (2)를 붙여야한다. 그래서 옮기려는 경로의 파일을 전부 조회할 수 밖에 없다.
fun generateUniqueName(type: String, inputName: String, parentId: String): String {
val names = when (type) {
"file" -> fileRepository.getNameListInFolder(parentId)
"trashBin" -> trashBinRepository.getNameListInFolder(parentId)
else -> folderRepository.getNameListInFolder(parentId)
}
val pattern = Pattern.compile("^${Regex.escape(inputName)}\\s*\\((\\d+)\\)$")
var maxNumber = 0
var isBaseNameExists = false
for (name in names) {
if (name == inputName) {
isBaseNameExists = true
} else {
val matcher = pattern.matcher(name)
if (matcher.matches()) {
val number = matcher.group(1).toInt()
maxNumber = maxOf(maxNumber, number)
}
}
}
return if (isBaseNameExists) {
"$inputName (${maxNumber + 1})"
} else {
inputName
}
}
유틸클래스를 만들고, 정규표현식으로 inputName의 존재여부를 찾고 matcher로 숫자를 가져와서 하나를 더하는 단순한 방식이다. 정규표현식은 GPT의 도움을 받아서 만들었다.
GPT가 대표적으로 잘하는게 정규표현식과 쿼리인 것 같다.
마치며
정작 고민도 많이하고, 개발단계에서 정책적인 변화가 너무 많았다.
케이스가 자꾸 추가되서 글쓸게 많을 줄 알아서 글 작성을 쓰고 보니가, 별로 글 쓸게 없었다.
가장 중요한건 끝자리의 숫자를 가져오는 정규표현식이었다.
다행히 GPT가 잘 만들어줘서 내 노력을 확 줄여줬다.
정규표현식이 필요하다 싶으면 GPT를 적극적으로 사용해보자.
'개발 > 뭔지모르면여기' 카테고리의 다른 글
해외 결제를 위한 Stripe 사용해보기 with. SpringBoot + Kotlin (0) | 2025.05.26 |
---|---|
IOS에서 올려주는 NFD 방식을 NFC로 마이그레이션하기 with. PostgreSQL, Java, Kotlin (0) | 2025.04.10 |
언제나 복잡한 이름 순 정렬 구현하기 (0) | 2025.04.07 |
고유한 객체 ID를 만들어보자 (UUID vs SnowFlake, 커스텀 ID 생성) (1) | 2025.02.10 |
AWS CloudFront + S3 에서 발생한 CORS 문제 해결하기 (1) | 2024.10.21 |
- Total
- Today
- Yesterday
- object
- serverless
- AOP
- MySQL
- 후기
- EKS
- Log
- Kotlin
- 스프링부트
- 오블완
- ChatGPT
- terraform
- Spring
- springboot
- GIT
- 람다
- S3
- CloudFront
- CORS
- AWS
- 티스토리챌린지
- lambda
- JWT
- cache
- OpenAI
- docker
- AWS EC2
- elasticsearch
- java
- 후쿠오카
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |