-
Notifications
You must be signed in to change notification settings - Fork 174
Protocol parts are missing speaker_id for mks #833
Comments
I edited the description to fix the RTL |
not sure I understood the problem, could you write some specific example of a problem which will be fixed by this? |
No protocol part in Oknesset has speaker_id field populated.. Code isn't handling this. not sure for how long but for quite a while :( |
Example: for previous end of moshav mary wanted to release talking statistics by coalition/opposition for vaadat haksafim |
@OriHoch does knesset-data-django has person class or should I pass the available persons from the calling methods |
@alonisser knesset-data-django has dependency on Open Knesset however, we strive to drop the dependency of knesset-data-django on open knesset at some point.. so I would like to keep this to a minimum having said that - feel free to write the code in Open Knesset if it's easier for you at the moment |
I'll have a look at this problem because I remember it was working correctly |
ok, looks like it's a very old bug (would be interesting to see if it ever worked) yes, it will be a very good enhancement - to be able to have ID of persons linked to each protocol part regarding repository - I guess the right place to do it will be knesset-data-django as all relevant logic is already there |
minor cleanup and adaptions + a part of #833
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 שמתקנת אחורה כדי שיהיו לנו את הנתונים האלו
The text was updated successfully, but these errors were encountered: