Dlaczego funkcja zumero_sync musi być wywoływana wiele razy?

Question

Według dokumentacji zumero_sync:

Jeśli duża ilość informacji musi być pobierane z serwera, tej funkcji konieczne może być wywoływany więcej niż raz.

W mojej aplikacji na Androida, która używa Zumero, nie ma problemu; Wciąż dzwonię pod numer zumero_sync, dopóki wartość zwracana nie rozpocznie się od "0;".

Jednak teraz próbuję napisać skrypt administratora, który również synchronizuje się z plikami dbfiles serwera. Chciałbym użyć powłoki sqlite3 i przekazać skryptowi SQL do wykonania za pośrednictwem argumentów wiersza poleceń. Muszę zadzwonić pod numer zumero_sync w pętli (której SQLite nie obsługuje), aby upewnić się, że db jest w pełni zsynchronizowany. Gdybym musiał, mogłem wywołać sqlite3 w pętli (czytając jej wyjście, szukając "0;"), lub nawet napisać aplikację C++, aby natywnie połączyć funkcje SQLite/Zumero. Ale na pewno byłoby łatwiej, gdyby wystarczył jeden egzemplarz: zumero_sync.

Domyślam się, że moje prawdziwe pytanie brzmi: czy można zmienić zumero_sync, aby zakończyła synchronizację przed powrotem? Jeśli są przypadki, w których istniejące zachowanie jest bardziej użyteczne, może może istnieć parametr określający, który tryb ma być używany?

Answer 1

widzę dwa podstawowe pytania tutaj:

(1) Dlaczego zumero_sync() działają w ten sposób to robi?

(2) Czy to działa inaczej?

Najpierw odpowiem (2), ponieważ jest to łatwiejsze: Tak, może działać inaczej. Raczej moglibyśmy (i zapewne wkrótce to zrobimy) zaimplementować dodatkową funkcję o nazwie coś w rodzaju zumero_sync_complete(), która wykonuje [odwagę] zumero_sync() w pętli i zwraca po zakończeniu synchronizacji.

Nie zaimplementowaliśmy funkcji zumero_sync_complete(), ponieważ nie dodaje ona zbyt wiele wartości. To prosta pętla, więc możesz ją dobrze napisać. :-)

Er, z wyjątkiem środowisk skryptowych, które nie obsługują pętli. Podobnie jak powłoka sqlite3.

Odpowiedź na (1):

Protokół synchronizacji Zumero jest zaprojektowany, aby dać serwerowi elastyczność powrotu częściowe rezultaty, jeśli chce zrobić. A ze względu na zmniejszenie obciążenia serwera (i zwiększenie jego skalowalności) często trzeba to zrobić.

Biorąc pod uwagę, że jednym z powodów ujawnienia tego klientowi jest zwiększenie elastyczności klienta. Tak długo, jak robimy wielokrotne wycieczki, równie dobrze możemy dać klientowi możliwość zrobienia czegoś (np. Może zaktualizować pasek postępu) pomiędzy nimi.

Inną rzeczą, którą klient może chcieć wykonać pomiędzy iteracjami pętli, jest błąd.

Lub, w przypadku klienta wielowątkowego, może zająć się zmianami, które zaszły na kliencie podczas synchronizacji.

Co nasuwa pytanie, w jaki sposób należy zarządzać zamkiem?Czy przechowujemy blokadę zapisu sqlite podczas całej pętli? Lub tylko wtedy, gdy jest to absolutnie konieczne? Podsumowując: Solidna aplikacja prawdopodobnie zaimplementuje samą pętlę, aby mogła podejmować własne decyzje i zachować pełną kontrolę nad rzeczami.

Jednak, jak widać, powłoka sqlite3 nie ma pętli. I to nie jest aplikacja. I nie ma nici. Lub paski postępu. Jest to przypadek użycia, w którym prostsza i mniej wydajna forma zumero_sync() miałaby sens.