Firebase로 개발하는 동안 수동으로 콘솔에 데이터 레코드를 추가했지만 항목 하나를 잊어 버렸습니다. 이로 인해 앱이 다운되었습니다. 콘솔에서 문제를 해결했지만 Firebase의 데이터 지속성을 사용했기 때문에 원래 데이터 오류가 지속되어 충돌이 다시 발생합니다. 지속성을 해제하면 모든 것이 정상이지만 캐시 된 저장소가 업데이트되지 않습니다. 누구든지이 문제가 있었고 해결 방법을 찾았습니까?Firebase 캐시 재설정
캐시가 자동으로 업데이트되어야합니다. 이 문제는 백그라운드 스레드에서 발생하기 때문에 주 스레드에서 코드를 호출하는 동안 응용 프로그램 코드가 충돌하더라도 디스크 캐시를 업데이트 할 것으로 예상됩니다.
그런 경우가 아니라면 좋은 상태로 돌아 오는 가장 빠른 방법은 애플리케이션 데이터를 삭제하거나 완전히 제거/다시 설치하는 것입니다.
나는 또한이 문제에 직면 해 있으며 끝없는 충돌 시작 루프에서 덫을 놓는 사용자에 대해 잠을 자지 못했습니다.
제안 된대로 문제가 발생할 기회는 앱 시작과 이후의 Firebase 서버 캐시 업데이트 도착 사이의 시간 창에서 생성됩니다. 이 시간대에 캐시에서 데이터를 읽은 다음 데이터에 예상 값이 누락 된 경우 앱에서 데이터가 0이 아닌 것으로 가정하는 방식으로 데이터를 사용하는 경우 앱이 다운됩니다 . 캐시가 업데이트되기 전에 앱이 다운되면 캐시가 업데이트 될 기회가 없으며 사용자는 무한 루프에 빠져 장치의 메모리에서 앱 데이터를 지우지 않습니다.
지금까지 필자는 시작시 호출되는 코드에서 nil 값의 가능성에 대해보다 철저하게 지키면서이 문제를 처리했습니다. nil이 확인되고 불편하게 발견되면 상황에 따라 가능한 경우 (1) 가능하다면 더 이상 데이터 손상을 일으키지 않을 경우 앱이 nil 대신 적절한 값으로 대체하거나 그렇지 않으면 (2) app 몇 초 동안 대기 모드로 진입 한 다음 문제가있는 노드에서 새로운 읽기를 시작한 다음 시작 루틴을 다시 시도합니다.
아마도이 이야기의 도덕은 값이 예상치 못한 범위 내에 있거나 그렇지 않은 것으로 가정하지 않을 수도 있습니다. 수령시 값의 유효성을 검사하거나 사용 시점에 값을 확인하거나 두 가지 모두를 수행 한 다음 그에 따라 오류를 처리하십시오.
감사합니다. Frank, 정확한 데이터를 가져 오는 데 db call을 조건으로하여 문제를 해결할 수있었습니다. 즉, 캐시가 활성화되었을 때 처음에는 아무 일도 없었습니다. 추가로 다시 시작한 후 캐시를 다시 동기화 할 수있었습니다. 파이어베이스가 캐시를 비동기 적으로 새로 고치는 것 같지만 이것은 내 코드가 시작하는 것보다 느리게 발생합니다. 이런 종류의 문제로부터 보호하기 위해 코드에 추가 할 수있는 것이 있습니까? 문제가 발생했을 때 캐싱을 해제하고 db가 동기화되면 지속성을 유지할 수있는 가능한 솔루션을 생각하고 있습니다. –