Skip to content

עדכון דלתא: hash תוכן לכל טבלה במניפסט - #27

Merged
Y-PLONI merged 1 commit into
Otzaria:otzariafrom
palmoni5:feat/per-table-content-hash
Sep 7, 2026
Merged

עדכון דלתא: hash תוכן לכל טבלה במניפסט#27
Y-PLONI merged 1 commit into
Otzaria:otzariafrom
palmoni5:feat/per-table-content-hash

Conversation

@palmoni5

@palmoni5 palmoni5 commented Sep 7, 2026

Copy link
Copy Markdown
Member

מה השינוי

מוסיף למניפסט של כל patch שתי מפות אופציונליות, fromTableContentHashes ו-toTableContentHashes: ה-hash הלוגי של כל טבלה בנפרד (sha256 של זרם הבתים של הטבלה בלבד, כולל הקידומת table:<t>). ה-hash הכולל הקיים לא משתנה — הבתים שמוזנים לו זהים; המפות מחושבות באותו מעבר יחיד, בשני digests.

  • LogicalContentHasher.computeReport — מעבר יחיד, hash כולל + hash לכל טבלה (LinkedHashMap בסדר טבלאות ה-hash, כולל טבלאות חסרות). compute() מאציל.
  • ReleaseManifestWriter — פולט את המפות כאובייקטי JSON בסדר איטרציה; מושמטות כשריקות; שתיהן או אף אחת. fromContentHash/toContentHash נשארים חובה.
  • PatchPipelineCli — מחשב את הדוחות (ללא מעברים נוספים על ה-DB), מעביר לכותב, ושער האימות משווה גם לפי טבלה (whole-hash נשמר).
  • delta-updater/Manifest.kt — השדות עם ברירת מחדל ריקה; התנהגות ה-applier לא משתנה.
  • DELTA_UPDATE_WORKFLOW.md §1.4 — תיעוד המנגנון וכלל הלקוח.

למה

הלקוח מאמת היום את כל הטבלאות (כ-80% מקובץ של 6GB) בתוך ה-transaction, לכל patch בשרשרת. עם המפות הוא מאמת רק את הטבלאות שה-patch יכול היה לשנות, ובודק את השאר אחרי ה-commit בלי לחסום קריאה.

PRים מקושרים (מענפים נפרדים)

סדר מיזוג: PR זה + ה-updater קודם, ואז אוצריא.

איך נבדק

  • LogicalHashContractTest חדש מול fixture משותף עם הלקוח (generator/common/src/jvmTest/resources/logical_hash_contract.json, זהה-בתים ל-test/logical_hash_contract.json ב-updater; contract.yml מוסיף cmp): hash כולל, hash לכל טבלה, compute() ללא שינוי, hash של טבלה בודדת שווה לרשומה בריצה המלאה.
  • ReleaseManifestWriterTest מורחב (עם מפות / בלי / אחת בלבד → שגיאה).
  • :generator-common:jvmTest --tests '...common.patch.*' — 57/57 ירוק (JDK 25).
  • :delta-updater:jvmTest — כשל אחד קודם ולא קשור (DeltaUpdaterClientEndToEndTest "lucene failure after sqlite commit"), נכשל זהה על עץ נקי של otzaria.

…eContentHashes)

LogicalContentHasher.computeReport מחשב במעבר יחיד, בשני digests, את ה-hash הכולל ואת ה-hash של כל טבלה בנפרד (sha256 של זרם הבתים של הטבלה בלבד, כולל הקידומת). compute() לא השתנה — הבתים שמוזנים ל-digest הכולל זהים.

ReleaseManifestWriter פולט את שתי המפות כאובייקטי JSON בסדר טבלאות ה-hash (מושמטות כשריקות; שתיהן או אף אחת). PatchPipelineCli מחשב את הדוחות ומעביר אותן, ושער האימות משווה גם לפי טבלה. Manifest.kt של delta-updater מקבל את השדות עם ברירת מחדל ריקה.

הלקוח משתמש במפות כדי לאמת אחרי apply רק את הטבלאות שה-patch יכול היה לשנות, ולבדוק את השאר אחרי ה-commit בלי לחסום קריאה.

בדיקות: LogicalHashContractTest חדש מול fixture משותף עם הלקוח (logical_hash_contract.json, מושווה ב-contract.yml ב-cmp), ReleaseManifestWriterTest מורחב. תיעוד ב-DELTA_UPDATE_WORKFLOW.md §1.4.
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