מצב זמני מול התמדה

מקור הערך קובע מה יכול לשרוד

הפלט מחבר ערך למקורו

הפלט התקבל משני תהליכים נפרדים של Python 3.12.14. לשני התהליכים ניתן אותו JSON סינתטי; הקובץ נפתח במצב קריאה בלבד. סינתטי כאן פירושו שהמידע הומצא לצורך התרגיל ואינו שייך לאדם אמיתי. התהליך הראשון יצר הערה זמנית בזיכרון; השני התחיל מחדש ולא יצר אותה.

restart-result.txt

תהליך ראשון: הערת טיוטה בזיכרון = bring_adapter; מזהה בקשה מהקובץ = 31; מזהה ציוד = 7.
תהליך חדש: הערת טיוטה בזיכרון = null; מזהה בקשה מהקובץ = 31; מזהה ציוד = 7.
הקובץ נכתב מראש כחומר תרגול ונקרא בשני התהליכים.
לא בוצעו הפעלה מחדש של המחשב או בדיקת התאוששות מכשל.

בשורה הראשונה מופיעה bring_adapter, תווית שמשמעותה להביא מתאם. ההערה הזאת נוצרה בזיכרון התהליך הראשון. המספרים 31 ו־7 באותה שורה נקראו מהקובץ. לפני שמשווים תוצאות, הצמידו לכל אחד משלושת הערכים את המקור שלו.

בהרצה החדשה ההערה מוצגת כ־null: התהליך התחיל בערך ריק ולא קרא אותה ממקור שנשמר. מספר הבקשה ומזהה הציוד, לעומת זאת, נטענו שוב מהקובץ. ההבדל קשור ליצירה ולטעינה של הנתונים, ולא לעיצוב כפתור שיכול להציגם.

שורת ההכנה אומרת שהקובץ היה כתוב מראש. לכן הראיה מבססת קריאה של תוכן קיים בשני תהליכים. היא אינה מבססת כתיבה דרך טופס, גיבוי או שחזור אחרי כשל. גיבוי הוא עותק שמור של מידע שאפשר לחזור אליו אם המקור נפגע, ושחזור הוא החזרת המידע מאותו עותק למקום שבו משתמשים בו. את שניהם נלמד לעומק בשיעור ״גיבוי, שחזור וראיית הצלחה״. השתמשו בפלט רק לתחום שנבדק בו.

כדי לתכנן בדיקת שמירה במוצר, בחרו ערך חדש וציינו איזה רכיב יכתוב אותו ולאן. אחר כך הגדירו מה יופעל מחדש ומאין ייקרא הערך. השוו את הערך שנשלח לשמירה לזה שנקרא לאחר ההפעלה. בשלב הזה מכינים את הבדיקה; את ההרצה מבצעים בהמשך בסביבה מתאימה.

מקרה ליישום

רשימת קניות צריכה לחזור בפתיחה נוספת, אך סימון רגעי של פריט נעלם במכוון בסגירת המסך. מה זמני כאן, ואיזו בדיקה תוכיח את השמירה של הרשימה?

בקשו מהסוכן מקום, משך חיים ואירוע איפוס לכל ערך, עם הפרדה בין טיוטה לבקשה שהתחייבו לשמור.

בקשו ערך סינתטי שחזר מהמקור הצפוי אחרי התחלה חדשה של הרכיב. הבהירו אם נבדקה כתיבה או רק קריאת קובץ מוכן.