Today I Learned
날짜
2024년 7월 16일 화요일
내용
이름을 잘 짓자
어제 기능을 완성했지만, 프론트와 싱크를 맞추는 과정에서 발생하는 문제들이 있어 여러가지 수정 작업에 들어갔다. import_log 를 생성할 때, 처음 상태의 기본값을 “WAITING”으로 설정했었다. 이후 로그의 생성 순서대로 “IMPORTING”으로 변경하면서 처리하면 될거라고 생각했기 때문이다. 문제는, 데이터 업데이트를 시작한 직후 프론트에서 데이터 조회 요청을 다시 보내는데 이때 “WAITING”이 반환되는 점이다. 이러면 프론트에선 그 로그에 대해서 지속적으로 상태를 추적하지 않는다. “IMPORTING” 중인 로그만 10초에 한번씩 상태를 추적하기 때문. WAITING인 것들을 굳이 상태가 변했는지 추적할 이유가 없는 것은 당연하다.
따라서 로직을 바꿔, 우선 IMPORTING으로 생성하고, 현재 진행중인 작업이 있다면 WAITING으로 변경하도록 바꾸었다. 이러면 생성 직후 요청이 와도 IMPORTING이 반환되서 추적하지 않는 문제에서 자유로워졌다. 아직 내 짬에는 프론트까지 고려하는 시야가 부족하다..
이외에도 상태추적에 관한 데이터들 형식이 맞지 않아 고생했다. 각 로우데이터의 상태는 2가지다. Importing_status와 update_status. 전자는 처음 생성 후 진행되는 업데이트나 수동 업데이트 때의 상태를 반환하는데 스키마 값을 준다. 후자는 매일 아침 주기적으로 자동처리되는 업데이트가 잘 진행되었는지를 나타낸다. 예를들어,
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
class RawDataImportStatus(IntEnum, Enum):
"""
ENUM: 로우데이터 수집 상태
| key | value | description |
| --- | --- | --- |
| FAILED | 0 | 실패 |
| CREATE_WAITING | 1 | 스프레드시트 생성 대기 중 |
| UPDATE_WAITING | 2 | 실시간 업데이트 대기 중 |
| CREATING | 3 | 스프레드시트 생성 중 |
| IMPORTING | 4 | 플랫폼에서 데이터 수집 중 |
| INSERTING | 5 | 스프레드시트에 데이터 삽입 중 |
| ADDING | 6 | 템플릿 추가 중|
| SUCCESS | 7 | 완료 |
"""
FAILED = 0
CREATE_WAITING = 1
UPDATE_WAITING = 2
CREATING = 3
IMPORTING = 4
INSERTING = 5
ADDING = 6
SUCCESS = 7
class RawDataImportFailReason(IntEnum, Enum):
"""
ENUM: 데이터 임포팅 실패 사유
| key | value | description |
| --- | --- | --- |
| SPREADSHEET_CREATE_FAILED | 1 | 스프레드시트 생성 실패 |
| API_ERROR | 2 | API 에러 |
"""
SPREADSHEET_CREATE_FAILED = 1
API_ERROR = 2
# 데이터 형식 예시
{
"raw_data": {로우데이터 관련 값들},
"importing_status": RawDataImportStatus.SUCCESS.value,
"update_status": False,
"update_status_reason": ,
}
저 update_status_reason에 들어갈 값에 대해 헷갈렸다. 내가 데이터베이스에서 raw_data 테이블과 import_log 테이블 모두에 “status_reason” 이라는 필드를 만들어놨기 때문이다. raw_data의 st atus_reason 에는 정해진 틀대로 “오늘 아침 주기적인 자동 업데이트가 실패한 이유”가 들어간다. 따라서 RawDataImportFailReason 의 값이 들어가야 한다. 반면 import_log에 들어가는 status_reason은 에러 텍스트를 넣기 위한 필드였다. 꽤 복잡한 과정이 반복되야 하고, 아직 서비스 초반이라 어떤 오류들이 발생하는지 파악하기 위해 만들어놓은 필드다.
위치가 다르더라도, 목적과 내용이 비슷해 보이는(사실 전혀 다른) 필드가 동일한 필드명을 가지니 내가 헷갈렸다. 심지어 두 테이블은 연관된 테이블이라 더욱.. 나야 만든 사람이니까 결국 찾았지, 처음 보는사람이 보면 아마 전혀 몰랐을 거다.
처음에 이름 지을때 잘 지었어야 했다. 테스트 서버 배포 전에 싹 정리해야겠다.
회고
AWS는 온갖 권한이 다 나눠져있다. 매번 요청하기, 풀어주기 참 번거롭다…
