Jak aktualizować lokalną bazę danych parse.com przyrostowo?

Question

Mam aplikację opartą na parse.com z funkcjami offline, gdzie cała baza danych jest przechowywana lokalnie (localStorage na klientach internetowych i lokalna baza danych parse.com na klientach mobilnych). Szukam rozwiązania projektowego, aby wydajnie aktualizować lokalną bazę danych z najnowszymi zmianami w zdalnej bazie danych. Opcje, które mogłem pomyśleć to:

1. Kronikowanie z kodem wyzwala. Ustaw wyzwalacze kodu chmury (after Save, afterDelete) dla każdego obiektu i dodaj dziennik do tabeli dziennika za każdym razem, gdy obiekt zostanie zapisany lub zniszczony. Klienci będą przesyłać kwerendy do tabeli aktualizacji i pamiętać lastUpdateTime dla kolejnych żądań.

   Plusy: a) możemy otrzymać bardzo szczegółowe streszczenie tego, co zostało zmienione i kto dokonał zmiany. b) wszelkie zmiany są natychmiast dostępne dla innych klientów (np wezwanie stół odpytywania powiadomień w czasie rzeczywistym z małymi opóźnieniami)

   Wady: a) nie może być zbyt wiele wpisów w tabeli

2. księgowaniem z pracą w tle. Skonfiguruj zadanie działające w tle, które wysyła zapytania do wszystkich tabel przez updatedAt, zapełnia tabelę dziennika i zapisuje numer lastUpdateTime dla kolejnych żądań.

   Plusy: a) mniej wpisy w tabeli dziennika

   Wady: a) zmiany są dostępne z nieprzewidywalnym opóźnieniem (nie nadaje się do powiadomień w czasie rzeczywistym), b) nie mogą śledzić usuwa istnieje nadal potrzeba aby ustawić inną stół do śledzenia usuwa lub wdrożenia miękkiego kasowania c) mniej szczegółów w dzienniku (np gdy obiekt jest tworzony przez jednego użytkownika i usunięty przez innego użytkownika, nie będziemy wiedzieć, kto stworzył przedmiot)

3. nie czasopismo. Wszyscy klienci przesyłają zapytania do wszystkich tabel przez updatedAt i przechowuje lastUpdateTime dla kolejnych żądań.

   Plusy: a) łatwe do wdrożenia, b) zmiany są natychmiast dostępne

   Wady: a) sam problem z usuwaniem jak w , b) nieefektywne (wierzę, że odpytywanie 20+ tabel przez wszystkich klientów nie jest to dobry pomysł

Mamy również interfejs, gdzie użytkownik może przejrzeć ostatniej aktywności (który zmienił co), więc niby skłaniają się ku liczby podejście, ale potencjalna wielkość stołu martwi mnie.

Answer 1

Klient potrzebuje możliwości odzyskania niezależnie od bieżącego stanu. Jest to bardzo ważne, jeśli używasz pamięci lokalnej, która może zostać wyczyszczona przez użytkownika. W takim przypadku potrzebujesz stanu zwrotnego. Dodatkowo klient musi mieć możliwość pobrania tylko wymaganej transakcji/istotnej dla niego.

1. Wdrożenie sklepu transakcji na backend
2. stworzenie mechanizmu odzyskiwania w przypadku localStorage nieaktywny jest uszkodzony
3. kroniki z kodem wyzwala lub wykorzystanie Źródło zdarzenia mechanizmu dB, dzięki czemu masz pełną historię i może używaj tego do budowania tabel dla klienta.

Podsumowując - Zmodyfikowane z dziennikiem wyzwalaczy Code (Modified odzyskać i zapisywania stanu do klienta w serwerze i za pomocą które do wyszukiwania danych)