This is makes it hard to do data analysis on this data
Further explanation of the issue and the solution (from an email correspondence between me and @maryLoi )
ה Headers של חלקי הפרוטוקול הם מידע "רך" וקשה מאוד להשתמש בו לשאילתות מועילות ומבוססים בעצם על Parsing של מבנה הדף, יכול להיות בהם שם, שם שגוי, שם בסדר לא נכון, כינוי, תעתיקים שונים של השם, שם בתוספת תארים וכו'. אפשר להשתמש בזה לשאילתא "כמעט" מדוייקת בredash אבל לא בשביל להציג מידע אינטראקטיבי למשל באתר על מה החכים עושים\, איפה מדברים וכמה וכו' בפרט בהשוואות בין ועדות (השערה שלי שהתעתיקים יחסית עקיבים בתוך אותה ועדה כל עוד יש אותם פרוטוקוליסטים, אבל משתנים שאלו משתנים או בין ועדות)
הפעולה שצריך לעשות היא לתקן את תהליך הבניה של Protocol parts כדי שיחובר הspeaker הנכון. אנסה לפרט את האלגוריתם ומבנה הקוד הרצוי כפי שאני מבין אותו,
לProtocolPart יש Foreign key ל Person (באמצעות שדה speaker) ואותו צריך לאייש בתהליך הזה
המודל הזה Person מחובר לMember (חבר הכנסת) מצד אחד ויש לו PersonAliases מהצד השני שכוללים מיפויים של שם חבר הכנסת שנתקלנו בהם לאותה ישות כל למשל:
[<PersonAlias: עיסאוי פריג -> עיסאווי פריג>, <PersonAlias: פריג עיסווי -> עיסאווי פריג>, <PersonAlias: עיסאווי פריג' -> עיסאווי פריג>, <PersonAlias: עיסאווי פריג -> עיסאווי פריג>, <PersonAlias: עיסווי פריג -> עיסאווי פריג>, <PersonAlias: עיסווי פריג -> עיסאווי פריג>]
[<PersonAlias: מועלם-רפאלי שולי -> שולי מועלם-רפאלי>, <PersonAlias: שולי מועלם רפאלי -> שולי מועלם-רפאלי>, <PersonAlias: שולי מועלם -> שולי מועלם-רפאלי>, <PersonAlias: שולי רפאלי -> שולי מועלם-רפאלי>]
[<PersonAlias: רחל שלי יחימוביץ' -> שלי יחימוביץ>, <PersonAlias: שלי יחימוביץ׳ -> שלי יחימוביץ>, <PersonAlias: שלי ייחימוביץ -> שלי יחימוביץ>, <PersonAlias: שלי ייחימוביץ׳ -> שלי יחימוביץ>]
[<PersonAlias: שרן השקל -> שרן השכל>, <PersonAlias: שרן הסקל -> שרן השכל>, <PersonAlias: שרן הסכל -> שרן השכל>]
[<PersonAlias: זנדברג תמר -> תמר זנדברג>, <PersonAlias: תמי זנדברג -> תמר זנדברג>]
מהדוגמא למעלה נראה לי שהבעייתיות של שימוש "נאיבי" בחילוץ שמות member עם Like של sql ברורה
אנחנו כבר "יודעים" מי חברי הכנסת שהשתתפו בישיבה אז זה מידע שאפשר להתחיל ממנו, לבנות את המיפוי של שמות אפשריים (כל הAliases של הPerson שמחוברים לMembers שהשתתפו בCommitteeMeeting הספציפי ל available_person_aliases_mapping
ואותו להזין לאובייקט ProtocolPartHeaderParser שיקבל את הטקסט של הHeader ואת available_person_aliases_mapping והוא יחזיר person אם הצליח שיוזן לשדה Speaker
הייתרון בזה הוא שאנחנו מבודדים את תהליך "החילוץ" מהclass הגדול והמלוכלך והקשה לבדיקה למשהו שאפשר לעשות לו Unit testing מכל הכיוונים וכך גם עתידית נוכל להרחיב ולהוסיף ולתקן אותו
ובהמשך (או עכשיו אם אתה בעניין) להוסיף גם ניסיון חילוץ שני אם הראשון לא הצליח למצוא התאמה ישירה עם שימוש בdifflib כמו שעושים במתודת find של NameAwareManager לדוגמא
אחרי שמתקנים את המתודה ביצירה create_protocol_parts (גם בcommiteeMeeting מודל וגם בplenum - אין לי מושג למה יש שתים ומה ההבדל בדיוק) , צריך גם לבנות management_command של django שמתקנת אחורה כדי שיהיו לנו את הנתונים האלו
Perhaps should be opened in knesset-data/django/python since part of the api moved there
This is makes it hard to do data analysis on this data
Further explanation of the issue and the solution (from an email correspondence between me and @maryLoi )
הפעולה שצריך לעשות היא לתקן את תהליך הבניה של Protocol parts כדי שיחובר הspeaker הנכון. אנסה לפרט את האלגוריתם ומבנה הקוד הרצוי כפי שאני מבין אותו,
לProtocolPart יש Foreign key ל Person (באמצעות שדה speaker) ואותו צריך לאייש בתהליך הזה
המודל הזה Person מחובר לMember (חבר הכנסת) מצד אחד ויש לו PersonAliases מהצד השני שכוללים מיפויים של שם חבר הכנסת שנתקלנו בהם לאותה ישות כל למשל:
[<PersonAlias: עיסאוי פריג -> עיסאווי פריג
>, <PersonAlias: פריגעיסווי -> עיסאווי פריג>, <PersonAlias: עיסאווי פריג' -> עיסאווי פריג>, <PersonAlias: עיסאווי פריג -> עיסאווי פריג>, <PersonAlias: עיסווי פריג-> עיסאווי פריג>, <PersonAlias: עיסווי פריג -> עיסאווי פריג>][<PersonAlias: מועלם-רפאלי שולי -> שולי מועלם-רפאלי>, <PersonAlias: שולי מועלם רפאלי -> שולי מועלם-רפאלי>, <PersonAlias: שולי מועלם -> שולי מועלם-רפאלי>, <PersonAlias: שולי רפאלי -> שולי מועלם-רפאלי>]
[<PersonAlias: רחל שלי יחימוביץ' -> שלי יחימוביץ>, <PersonAlias: שלי יחימוביץ׳ -> שלי יחימוביץ>, <PersonAlias: שלי ייחימוביץ -> שלי יחימוביץ>, <PersonAlias: שלי ייחימוביץ׳ -> שלי יחימוביץ>]
[<PersonAlias: שרן השקל -> שרן השכל>, <PersonAlias: שרן הסקל -> שרן השכל>, <PersonAlias: שרן הסכל -> שרן השכל>]
[<PersonAlias: זנדברג תמר -> תמר זנדברג>, <PersonAlias: תמי זנדברג -> תמר זנדברג>]
מהדוגמא למעלה נראה לי שהבעייתיות של שימוש "נאיבי" בחילוץ שמות member עם Like של sql ברורה
אנחנו כבר "יודעים" מי חברי הכנסת שהשתתפו בישיבה אז זה מידע שאפשר להתחיל ממנו, לבנות את המיפוי של שמות אפשריים (כל הAliases של הPerson שמחוברים לMembers שהשתתפו בCommitteeMeeting הספציפי ל available_person_aliases_mapping
ואותו להזין לאובייקט ProtocolPartHeaderParser שיקבל את הטקסט של הHeader ואת available_person_aliases_mapping והוא יחזיר person אם הצליח שיוזן לשדה Speaker
הייתרון בזה הוא שאנחנו מבודדים את תהליך "החילוץ" מהclass הגדול והמלוכלך והקשה לבדיקה למשהו שאפשר לעשות לו Unit testing מכל הכיוונים וכך גם עתידית נוכל להרחיב ולהוסיף ולתקן אותו
ובהמשך (או עכשיו אם אתה בעניין) להוסיף גם ניסיון חילוץ שני אם הראשון לא הצליח למצוא התאמה ישירה עם שימוש בdifflib כמו שעושים במתודת find של NameAwareManager לדוגמא
אחרי שמתקנים את המתודה ביצירה create_protocol_parts (גם בcommiteeMeeting מודל וגם בplenum - אין לי מושג למה יש שתים ומה ההבדל בדיוק) , צריך גם לבנות management_command של django שמתקנת אחורה כדי שיהיו לנו את הנתונים האלו