[Feat] Room 도입과 운동 기록 캐시 저장층 추가 - #591
Merged
Merged
Conversation
오프라인 캐시의 저장층입니다. 아직 아무도 이 DB를 주입받지 않습니다. - 모든 테이블에 memberId 컬럼을 두고 조회에 계정 조건을 겁니다 - 목록과 상세는 테이블을 나눴습니다. 한 테이블에 담으면 목록 응답을 저장할 때 detail과 location이, 상세를 저장할 때 date와 thumbnailUrls가 서로 덮여 사라집니다 - 목록의 date는 조회할 때 서버에 넘긴 날짜입니다. startedAt에서 파생시키면 자정을 넘긴 기록이 서버가 묶어준 날과 어긋납니다 - sortOrder는 서버 응답 순서입니다. SQL이 순서를 보장하지 않습니다 - 날짜는 ISO 문자열로 담아 사전순 비교가 시간순 비교가 되게 했고, 사진 목록은 JSON 컬럼입니다
계정 경계를 테이블보다 먼저 잠급니다. 로그아웃이나 계정 전환 때 이전 사용자의 데이터가 남으면 안 됩니다. - 세션을 지우는 경로가 MainViewModel.transitionToLogin()과 SettingFragment.clearLocalSession() 둘인데 모두 ClearSessionUseCase를 거치므로 삭제를 여기 한 곳에 연결합니다 - domain은 Room을 모르게 합니다. FcmTokenSyncScheduler와 같은 패턴으로 domain에 SessionDataCleaner 인터페이스를 두고 data 구현이 지웁니다
기존 API 호출을 RemoteDataSource로 옮기고 Room 접근을 LocalDataSource로 분리합니다. apiCallBuilder 계약과 화면 동작은 그대로입니다. - LocalDataSource가 memberId를 자기 안에서만 읽습니다. 호출부가 넘길 수 없으니 계정 조건을 빠뜨린 쿼리를 쓸 자리가 없습니다 - 캘린더와 목록은 구간을 비우고 다시 채웁니다. 서버 응답에는 운동한 날과 남아 있는 기록만 오니까 upsert만 하면 0건이 된 날과 삭제된 기록이 캐시에 계속 남습니다 - LocalDataSource는 아직 호출부가 없습니다. 읽기를 Flow로 바꾸는 건 #584입니다
6 tasks
디자인 문서 최종본의 원본 데이터 위치와 설계 규칙(D2, D4, D6)에 맞춥니다. - 행을 식별하는 값을 localId(UUID)로 바꾸고 serverId를 nullable로 뒀습니다. 오프라인에서 만든 기록은 서버 ID를 받기 전이라 서버 ID를 PK로 쓰면 들어갈 자리가 없습니다 - syncState 컬럼을 추가했습니다. 연산을 쌓지 않고 행마다 현재 상태만 둡니다 - 서버 목록 반영이 SYNCED 행만 교체합니다. 아직 못 올린 로컬 변경이 서버 목록 갱신으로 사라지면 안 됩니다 - 이미 캐시에 있던 기록은 localId를 이어 씁니다. 목록을 새로 받아도 그 기록을 가리키던 화면과 이미지가 같은 행을 계속 가리킵니다 - 읽기를 Flow 구독에서 1회 조회로 바꿨습니다. 화면은 진입할 때 한 번 읽고 그린 값이 저절로 바뀌지 않습니다 목록 상세 진입은 아직 서버 ID를 씁니다. 화면이 로컬 ID로 기록을 식별하게 바꾸는 건 #584입니다.
설계 규칙 6은 대기 행을 남기는 것과 서버 값으로 대체하지 않는 것을 둘 다 요구하는데 뒤쪽을 지키지 못하고 있었습니다. - SYNCED 행만 지우고 대기 행을 남겨도, 뒤이은 upsert가 그 localId를 그대로 써서 같은 행에 SYNCED와 서버 값이 들어갔습니다. 행을 지우지 않았을 뿐 결과가 같습니다. 이제 대기 행이 걸린 기록은 서버 항목 자체를 반영 대상에서 뺍니다 - 서버에서 기록의 날짜가 바뀌면 같은 serverId가 두 날짜에 남아 상세 조회가 어느 행을 집을지 정해지지 않았습니다. localId 조회에서 날짜를 가리지 않게 하고 옛 날짜 행을 정리합니다 - 서버 목록에서 사라진 기록의 상세가 남아 계속 읽혔습니다. 목록을 갈아끼울 때 함께 지웁니다 - 서버 ID가 없는 행을 -1로 내보내던 센티널을 없앴습니다. -1이 Long으로 멀쩡해 보여 그대로 서버 요청에 실릴 수 있었습니다 replaceSyncedListByDate는 삭제 조건과 localId 재사용, upsert가 한 트랜잭션에서 맞물려서 테스트를 붙였습니다. DAO를 대역으로 세워 선택 로직만 봅니다.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#️⃣연관된 이슈
Closes #581, Closes #583
📝작업 내용
오프라인 캐시의 저장층을 올립니다. 아직 어느 화면도 이 캐시를 읽지 않아서 동작에 보이는 변화는 없습니다. 화면을 Room 경유로 바꾸는 건 #584입니다.
Room은 entities가 빈 데이터베이스를 컴파일 에러로 막아서 #581만 따로 올릴 수 없었습니다. 그래서 #583의 Entity와 DAO를 함께 담았습니다.
Room 골격과 계정 스코프 (#581)
테이블 (#583)
캘린더 집계, 목록, 상세 셋입니다.
읽기와 쓰기 (#583)
ktlintCheck, testDebugUnitTest, assembleDebug 모두 통과했습니다.
스크린샷 (선택)
💬리뷰 요구사항(선택)
1. 목록과 상세 테이블 분리
upsert 충돌을 피하려고 나눴는데 title, startedAt, endedAt이 양쪽에 중복됩니다. 한 테이블에 두고 부분 컬럼 UPDATE 쿼리 두 개로 가는 선택지도 있었습니다. 어느 쪽이 나을지 봐주시면 좋겠습니다.
2. 상세 진입 경로가 아직 서버 ID입니다
행은 localId로 식별하는데 화면은 exercise_nav_graph.xml의 recordId(Long)로 상세에 들어옵니다. 그래서 getDetailByServerId를 남겨뒀습니다. 화면을 localId 기준으로 바꾸는 건 #584인데, 그때까지 이 두 경로가 공존하는 게 괜찮을지 봐주세요.
3. DAO 테스트를 뺀 판단
메모리 DB로 DAO를 테스트하려면 Robolectric이 필요한데(CI가 testDebugUnitTest만 돌려서 androidTest는 실행되지 않습니다), data 모듈에 테스트가 하나도 없는 상태에서 90MB 인프라를 들이는 게 맞나 싶어 뺐습니다. 지금 SQL은 단순 조회고 틀리면 화면에 바로 보입니다. 다만 CRUD 단계의 syncState 전이와 대기 행 보존 쿼리는 성격이 달라서 그때는 다시 넣을 생각입니다.