[1.1.0/AN-FEAT] 룸 엔티티 수정 대응(destructive-recreation)

[sh1mj1]

• closed [1.1.0/AN-FEAT] 룸 엔티티 수정 대응(destructive-recreation) #354

작업 영상

그런 건 없어요~

작업한 내용

• 룸 엔티티 변경에 대해 대응한다.

PR 포인트

결론

---

기존: 앱을 켤 때마다 항상 룸 DB 드롭하고 새로 만듭니다.
변경됨: 룸 엔티티의 정보가 바뀌었을 때만, 룸 DB 를 드롭하고 새로 만듭니다.

룸 AutoMigration 은 안 썼습니다.
이틀 삽질 엄청했는데 결과는 코드 3줄 넣으면 되는 거였네요 ㅋㅋㅋㅋㅋ

상황 설명

---

상황 설명을 드릴게요.

1. 현재 구조: DB 에서 포켓몬 조회합니다. 비어있으면 서버로부터 요청하여 DB 에 포켓몬 데이터들을 저장합니다..
2. DB 엔티티에 backImageUrl 이 추가되었으니, DB 에 저장된 데이터들을 업데이트 해야 한다.
3. 즉, 우리는 서버로부터 받은 포켓몬 데이터를 다시 DB 에 저장해야 합니다.

방법1.
그러러면, 전체 포켓몬 목록 API 를 호출해서 backImageUrl 을 필터링 한 다음에 DB 에 데이터를 직접 넣어주어야 합니다.
이렇게 하면 기존 DB 데이터들은 유지하고 새로 추가된 데이터만 DB 에 넣어줄 수 있습니다.

방법2.
하지만 저는 그냥 룸 엔티티의 정보가 바뀌었을 때만, 룸 DB 를 드롭하고 새로 만들도록 구현했습니다.

방법 1 이 별로인 이유.

1. 공수가 너무 많이 듭니다. 단순 엔티티가 하나 추가되었는데 기존에 있던 데이터 칼럼과 비교하고 필터링하고 다시 넣어주는 로직이 생깁니다.
2. 만약 다음에 또 다른 엔티티가 추가된다고 하면, 일일이 다시 로직을 수정해야주어야 합니다.

방법 2가 괜찮은 이유.

1. 공수가 적게 든다.
2. 캐시된 데이터의 손실이 큰 문제가 되지 않는다.

🚀Next Feature

글쎄요..?
일단 미션 좀 하고 내일 팀원들에게 의견 물어볼게요

[sh1mj1]

.

[sh1mj1]

fallbackToDestructiveMigration()를 사용하는 방식은, 파괴적 마이그레이션.
기존 데이터베이스를 제거하고 새로 생성하는 방법입니당.
이 방식은 기본적으로 앱의 데이터베이스 스키마가 변경되면, 데이터베이스를 삭제하고 새롭게 생성하는 방식입니다~

[kkosang]

db의 버전만 바꿔주면 기존에 있던 데이터베이스를 삭제하고 새롭게 생성하는건가유??

[sh1mj1]

엔티티가 변경되었을 때만 기존 DB 를 삭제하고 새로 생성합니다.

[murjune]

오 신기하네요! 근데 scheme 바뀌면 version 을 매번 올려줘야하는건 동일할까요?

[sh1mj1]

근데 scheme 바뀌면 version 을 매번 올려줘야하는건 동일할까요?

네 맞아요~

[kkosang]

오홍 이런 방법도 있군요~~ 굿입니다 심지 !

[kkosang]

db의 버전만 바꿔주면 기존에 있던 데이터베이스를 삭제하고 새롭게 생성하는건가유??

[JoYehyun99]

수고많으셨습니다 심지!! 👍
사용자의 선택 데이터가 아닌 포켓몬 전체 목록에 대한 데이터기 때문에 가능한 전략일 것 같군뇨 👀
좋은 선택인 것 같슴니다!!
만약 이 후에 선택 데이터를 저장해야 하는 테이블이 생기면 그 때는 AutoMigration으로 관리하면 좋을 것 같아요~~

[murjune]

고생하셨습니다 심지!! 👏

고생해주신 덕분에 팀원들 모두 db 마이그레이션에 대해 좀 더 깊이 있는 지식을 학습할 수 있었습니다 ㅎㅎ

[murjune]

오 신기하네요! 근데 scheme 바뀌면 version 을 매번 올려줘야하는건 동일할까요?

[murjune]

/noti 마지막 리뷰 달았습니당 질문 하나만 답해주시면, 바로 머지하셔도 될 것 같아유 ~~ 심지 최고 👍