Skip to content

עדכון ספרייה: בחירת מסלול על דלתא כבדה, מד התקדמות בהחלה, שימוש חוזר ב-patch ובדיקת מקום (issue #1211) - #1223

Merged
Y-PLONI merged 4 commits into
Otzaria:devfrom
palmoni5:library-update-heavy-delta-1211
Sep 8, 2026

Conversation

@palmoni5

@palmoni5 palmoni5 commented Sep 7, 2026

Copy link
Copy Markdown
Member

סוגר את #1211.

מה

  1. בחירת מסלול על דלתא כבדה — כשה-planner מסמן isHeavyDelta ויש DB מלא, העדכון לא רץ אוטומטית אלא עובר לסטטוס חדש needsRouteChoice בפריט החיווי הרגיל, עם שתי פעולות שקולות והגדלים של כל אחת: עדכון דלתא (הורדה קטנה, החלה ארוכה של עשרות דקות ומעלה; מתאים לרשת איטית) או הורדה מלאה (הורדה גדולה, החלה קצרה). ConfirmHeavyDelta מריץ את הדלתא; ConfirmFullDownload עובר ל-toFullDownloadFallback ומכניס את התוכנית ל-state כדי שה-reconcile של האינדקס ירוץ. בלי DB מלא הדלתא רצה כרגיל עם הערה שההחלה עשויה להימשך זמן רב. checkForUpdate מעביר את גודל seforim.db ל-planner.
  2. מד התקדמות אמיתי בהחלהonApplyProgress של החבילה מועבר מה-isolate כרשומה מתויגת ומוצג כ-applyProgress בשלבי upserts/deletes, דרך הוויסות הקיים (200ms). עד היום "מוסיף ומעדכן רשומות" היה ספינר בלבד, גם על 3GB.
  3. שימוש חוזר ב-patch פרוסStreamingPatchDownloader מחזיר patch-*.db קיים אחרי אימות גודל ו-sha256 (ב-isolate) במקום להוריד שוב 585MB; אי-התאמה מוחקת ומורידה. קובצי patch שאינם חלק מהתוכנית נמחקים בסיום תוכנית וגם לפני בדיקת המקום, כדי ששריד של 3GB לא ינעל משתמש על "אין מקום".
  4. מקום פנוי במסלול הדלתא — לפני כל צעד: הקאש צריך דחוס+פרוס (בניכוי מה שכבר קיים), ותיקיית ה-DB צריכה מרווח WAL בגודל ה-patch הפרוס; אותה לוגיקת same-volume כמו במסלול המלא. LibraryUpdateDiskSpaceException ממופה להודעה אחת (LibraryMessages.updateDiskSpaceError) בשני המסלולים, ואינו מציע הורדה מלאה שדורשת עוד יותר מקום.

למה

משתמש דיווח שהעדכון "תקוע" על "מוסיף ומעדכן רשומות" מעל חצי שעה, ושסגירה ופתיחה מחדש התחילו את ההורדה מאפס. השורש: patch v23→v27 של 585MB דחוסים / 3.05GB פרוסים (id churn במחולל, מטופל ב-Otzaria/SeforimLibrary#28), שה-planner בחר כי השווה רק גודל הורדה. ההחלה של 3GB לתוך DB של 6.4GB בטרנזקציה אחת אורכת שעה ומעלה; הורדה מלאה של 1.4GB הייתה נגמרת בדקות. עם זאת, ברשת איטית מאוד 585MB עדיפים על 1.4GB, ולכן הבחירה נשארת אצל המשתמש.

תלות וסדר מיזוג

בדיקות

flutter analyze (כל הפרויקט) נקי. flutter test test/library_update/ test/widgets/work_status_overlay_test.dart test/library/view/library_update_button_test.dart — 159 עברו, 1 skip ידוע (libzstd), על Flutter 3.47.2 כמו ב-CI. בדיקות חדשות: needsRouteChoice ושני מסלולי האישור, דלתא כבדה בלי חלופה, applyProgress ב-upserts, localDbSizeBytes, שימוש חוזר + hash שגוי, בדיקת מקום (same-volume, נפרד, פרוס קיים, ניקוי לפני הבדיקה), מיפוי חוסר מקום בשני המסלולים, רינדור שתי הפעולות.

החלטות שנסגרו (קומיט שני, 59a0d87)

  • סף 0.25 בלקוח מול 0.5 בשרת — נשאר. שני הספים עונים על שאלות שונות: השרת שואל "האם ה-patch לגיטימי" והוא רשת הביטחון לגרסאות ישנות שבוחרות דלתא לפי גודל ההורדה בלבד, ולכן חייב להיות רופף כדי לא להפיל מיגרציה לגיטימית (כמו dhDisplay) להורדה מלאה לכולם. הלקוח שואל "האם הדלתא עדיין ברור שעדיפה". הכלל שתועד בחבילה: יחס הלקוח נשאר לפחות פי 2 קטן מיחס השרת, כך שהלקוח תמיד יספיק לשאול לפני שהשרת כופה. ייבחן מחדש מול גודל ה-patch האמיתי של v28.
  • טבעת 0% בפריט הבחירה → אייקון שאלה. סוג חיווי חדש WorkStatusKind.awaitingInput בשתי שורות ה-overlay: אין עבודה רצה, יש שאלה. טבעת ריקה משדרת "תקוע" — בדיוק התסמין של זמן עידכון הספריה #1211.
  • אימות sha256 של patch לשימוש חוזר → מד + ביטול, בלי לוותר על האימות. קובץ קטוע הוא בדיוק המקרה שהמסלול אמור לתפוס. ה-hash רץ ב-isolate שמדווח כל 8MB ומקבל הודעת ביטול; מוצג כשלב verifying עם אחוזים, וה-BLoC מאפשר ביטול בדלתא כל עוד לא התחילה כתיבה ל-DB. ביטול משאיר את הקובץ לריצה הבאה. דורש את ה-hook onVerifyProgress שנוסף ב-החלת patch עם מד התקדמות אמיתי וסימון דלתא כבדה (0.5.0) otzaria_library_updater#11 (קומיט 30bf3ff).

בדיקות לקומיט השני: flutter analyze נקי; flutter test test/library_update/ test/widgets/work_status_overlay_test.dart — כולם עברו (151 + 1 skip ידוע). חדשות: דיווח התקדמות אימות מ-0 עד גודל הקובץ, ביטול באמצע אימות משאיר את הקובץ, פריט awaitingInput בלי טבעת ובלי 0%.

palmoni5 and others added 4 commits September 8, 2026 07:24
…ב-patch ובדיקת מקום (issue Otzaria#1211)

patch v23→v27 של 3GB פרוסים הוחל במשך שעה ומעלה כשהחיווי מציג ספינר בלבד, וסגירת התוכנה גרמה להורדה מחדש של 585MB. הדלתא נבחרה כי ה-planner השווה רק גודל הורדה.

בחירת מסלול: כשה-planner מסמן isHeavyDelta ויש DB מלא, העדכון לא רץ אוטומטית אלא עובר ל-needsRouteChoice עם שתי פעולות שקולות — עדכון דלתא (הורדה קטנה, החלה ארוכה; מתאים לרשת איטית) או הורדה מלאה (הורדה גדולה, החלה קצרה) — עם הגדלים. ConfirmHeavyDelta מריץ את הדלתא; ConfirmFullDownload עובר ל-toFullDownloadFallback ומכניס את התוכנית ל-state כדי שה-reconcile של האינדקס ירוץ. בלי DB מלא הדלתא רצה עם הערה שההחלה עשויה להימשך זמן רב. checkForUpdate מעביר את גודל seforim.db ל-planner.

מד התקדמות: onApplyProgress של החבילה מועבר מה-isolate כרשומה מתויגת ומוצג כ-applyProgress בשלבי upserts/deletes, בוויסות הקיים של 200ms.

שימוש חוזר: StreamingPatchDownloader מחזיר patch פרוס קיים אחרי אימות גודל ו-sha256 במקום להוריד שוב; אי-התאמה מוחקת ומורידה. בסיום תוכנית וגם לפני בדיקת המקום נמחקים קובצי patch-*.db שאינם חלק מהתוכנית, כדי ששריד של 3GB לא ינעל משתמש על "אין מקום".

מקום פנוי: בדיקה לפני כל צעד דלתא — הקאש צריך דחוס+פרוס (בניכוי מה שכבר קיים) ותיקיית ה-DB צריכה מרווח WAL בגודל ה-patch הפרוס. LibraryUpdateDiskSpaceException ממופה להודעה אחת בשני המסלולים ואינו מציע הורדה מלאה, שדורשת עוד יותר מקום.

דורש seforim_library_updater 0.5.0 (Otzaria/otzaria_library_updater — PR נלווה). ה-CI אדום עד מיזוגו כי pubspec.yaml עוקב אחרי main.
…atch לשימוש חוזר (issue Otzaria#1211)

סוג חיווי חדש WorkStatusKind.awaitingInput: פריט שמחכה להחלטת המשתמש מוצג עם אייקון שאלה ולא עם טבעת התקדמות ריקה שנראית כמו עבודה שנתקעה.

אימות ה-sha256 של patch פרוס (3GB, עשרות שניות) רץ ב-isolate שמדווח התקדמות כל 8MB ומקבל הודעת ביטול; הריפוזיטורי מעביר את זה כשלב verifying עם applyProgress, וה-BLoC מאפשר ביטול בדלתא כל עוד לא התחילה כתיבה ל-DB. ביטול משאיר את הקובץ לריצה הבאה.
@Y-PLONI
Y-PLONI force-pushed the library-update-heavy-delta-1211 branch from 2e61a9e to f3973f0 Compare September 8, 2026 04:45
@Y-PLONI
Y-PLONI merged commit 40dc1cd into Otzaria:dev Sep 8, 2026
9 checks passed
@palmoni5
palmoni5 deleted the library-update-heavy-delta-1211 branch September 8, 2026 07:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants