Active Record, או בקיצור ARֿ, היא שכבת ה ORM של ריילס.
סיפקתי הקדמה על AR בפוסט על ריילס (כולל למשל, חוקי הקשר בין שמות מחלקות לשמות טבלאות בבסיס הנתונים) ולא אחזור על מידע זה.
AR הוא מימוש של דפוס עיצוב בשם זהה, שהופיע לראשונה בספר של מרטין פאוולר.
כל מחלקת מודל של AR מתארת טבלה בבסיס הנתונים, כאשר מופע של המחלקה מתאר מצביע לשורה מסוימת בטבלה (Row).
אובייקט של מודל AR הוא לא מבנה נתונים פשוט - זוהי מחלקה עם מתודות לכל דבר. המתודות יכולות להיות helpers לעבודה עם נתונים (למשל: calculated fields או find_matching_x), או business logic של ממש - כל עוד הלוגיקה נוגעת לרשומה הבודדת בבסיס הנתונים או מה שהיא מייצגת. לוגיקה הנוגעת בכמה אובייקטים במערכת - תשב במקומות אחרים במערכת (ב Controller או ב Lib).
אין אכיפה ממשית שכללים אלו באמת נשמרים ע״י המפתחים, וזה עניין של אחריות אישית והיכרות עם הכללים.
דפוס ה AR משנה במעט את כללי ה MVC ה״קלאסי״ (כי המודל כולל עכשיו גם לוגיקה), והוא זוכה על כך גם לביקורת:
טענות אלו נכונות, אך אלו הבחירות התכנוניות של ריילס - ויש להן גם יתרון בצד השני: פרודקטיביות פיתח.
בניגוד לחלק מכלי ה ORM (קיצור של Object-Relational Mapping) האחרים, AR לא מנסה ״להחביא לגמרי״ את ה SQL. הגישה היא יותר גישה של ״בואו נהפוך את השימוש ב SQL ליותר DRY".
למשל, AR, תחסוך לנו את העבודה המעצבנת ב SQL של לציין שוב ושוב את שמות השדות הרלוונטיים (חשבו למשל על Join מורכב). מצד שני היא כן רואה בשימוש במידה מסוימת של SQL כהכרחי, ולכן מספקת מתודות כגון find_by_sql בהן מזינים שאילתת SQL.
לאחר שנתקלתי שוב ושוב בצורך ״לעקוף את ה ORM״ בעבר - הגישה הזו נראית לי מאוזנת ובריאה. בעוד ששימוש ב SQL הוא לא דבר מומלץ ב Hibernate (כי אז ה caches של Hibernate לא יהיו מעודכנים, למשל), בריילס הנחת העבודה היא ש SQL יהיה בשימוש מפעם לפעם.
מה המחיר ש AR שילמה על זה? כנראה בביצועים, ובמגוון היכולות שיש לכלי ORM ואינם מפותחים כ"כ ב AR.
מחיר סביר, לטעמי.
AR, כמו ריילס, הוא כלי שנכתב בחשיבה ראשונית על אפליקציות CRUD (״מילוי טפסים והפקת דוחות״) ופחות לאפליקציות שמטפלות בלוגיקה מורכבת, או זקוקות לביצועים גבוהים.
כמו כל כלי ORM אחר - הביצועים ש AR תשיג הם אולי טובים יותר בממוצע מהביצועים של קוד שנכתב ללא חשיבה כלל על ביצועים, אך הם לא יוכלו להתחרות במפתח שמכוון לביצועים גבוהים.
מודל (Model, של MVC) של AR היא מחלקה שיורשת ממחלקת הבסיס ActiveRecord::Base.
AR יצפה ששם המחלקה יופיע בצורת יחיד, ושם טבלה המתאימה - בצורת רבים (ע״פ החוקים שתיארתי בפוסט הקודם).
אין צורך להגדיר במחלקת המודל את העמודות השונות של הטבלה: בזמן ריצה AR יתשאל את בסיס הנתונים, ימצא את העמודות, ותוסיף שדות ו getters/setters לגישה אליהם על מחלקת המודל.
מדוע? בכדי למנוע מצבים של חוסר עקביות בין בסיס-הנתונים לקוד, ולחסוך תחזוקה כפולה של השדות הקיימים על כל טבלה (עקרון ה DRY).
מאיפה, אם כן, מגיעה הסכמה לבסיס הנתונים?
לפעמים אנו כותבים אפליקציה המכוונת לסכמה קיימת. אם לא, אז הדרך העיקרית בריילס לעשות זאת היא בעזרת קוד ריילס, בשם Migration.
בתיקיית ה db בפרויקט ריילס נמצא כמה קבצים הקשורים לעניין:
ה״סקריפטים״ (מחלקות רובי) שבתיקיית ה migrate הן מה שמעדכן את הסכמה, והם מסודרים כך שיוכלו להעביר בסיס נתונים מ״מצב 5״ ל״מצב 6״ (שנוצר בעקבות שינויים במודל של האפליקציה), או לאחור מ ״מצב 6״ בחזרה ל״מצב 5״ (ככלי rollback).
את הסקריפטים האלו מריצים בעזרת פקודת rake db:migrate מה command line, בעוד שאת בניית הסכמה מחדש (על בסיס schema.rb) מפעילים בעזרת פקודת rake db:schema:load.
פקודות אלו נוגעות רק לסכמה. עבור הכנסת נתונים ראשוניים לבסיס הנתונים קיים הקובץ seeds.rb, שמופעל בפקודה rake db:seed.
פקודת rake db:setup, שנהוג להפעיל בהתקנת האפליקציה על מערכת חדשה, מפעילה בפועל גם db:create, גם db:schema:load ולבסוף את db:seed. ניתן לבחון את הסריפטים עצמם בגיטהאב.
בכדי לייצר migration חדש בד״כ משתמשים ב generator הבא:
ניתן לייצר את הקובץ ידנית, אך חשוב לשמור על שם קובץ עם timestamp בפורמט מדויק, מה שקל יותר להשיג בעזרת ה generator. שם הקובץ עשוי להראות משהו כמו:
כאשר ה״קישקוש״ בתחילתו הוא ה timestamp המתאר את זמן יצירת הקובץ.
הקובץ עצמו עשוי להראות כך:
change היא מתודת העבודה העיקרית. בתוכה נוכל לבצע שינויים בבסיס הנתונים כגון יצירת טבלה (כמו במקרה שלנו), הוספת או הרדת עמודה, או אינדקס, ועוד מספר פעולות. AR יידע להשתמש בתוכן המתודה בכדי לבצע את השינוי, וגם להחזיר אותו בחזרה למצב הקודם במקרה ונרצה לעשות מתישהו rollback (תקלות ב production, מישהו?).
יש מצבים בהם לא ניתן להסיק אוטומטית את הדרך חזרה, למשל: שינוי טיפוס של עמודה, או החלטה שמעתה לא יתקבלו nulls - בגלל שאין תשובה אחת לשאלה "מה לעשות עם הערכים הנוכחיים?". במקרים כאלה יש להשתמש בשתי מתודות אחרות: up (השינוי הרצוי) ו down (פעולת ה rollback) - והטיפול בשאלות הלא-ברורות.
AR מגדיר סט של כמה טיפוסי-ביניים בהן ניתן להשתמש, למשל: string, text, float, decimal, time, וכו׳
על כל עמודה ניתן להגדיר עוד properties, למשל null:false - עבור עמודה שנרצה שבסיס הנתונים יגן שלא תקבל ערך null.
בעזרת Adapter מתאים לכל בסיס נתונים, AR מחליט לאילו טיפוסים של בסיס הנתונים למפות את טיפוסי-הביניים שלו בפועל. למשל, האם text ישמר כ varchar, nvarchar, או CLOB. זהו סוג של שירות שאמור לחסוך למפתח את ההבנה העמוקה בין הטיפוסים השונים של בסיס הנתונים, ועבור רוב התסריטים - הבחירות שלו הן בהחלט טובות.
עבור בסיסי נתונים מסוימים, ה Adapter גם יתמוך בטיפוסים נוספים. למשל, אם אתם עובדים עם PostgreSQL, תוכלו להשתמש בטיפוסי AR בשם json או hstore או properties מסוימים - שיתמפו ליכולות של PostgreSQL.
AR ייצר getters ו setter על המודל עבור על עמודה, דרכם נוכל לגשת לנתונים.
עמודות עם טיפול מיוחד
אם לא הגדרתם בעצמכם את ה primary key (מה שמומלץ רק במצב של טבלה שכבר קיימת לפני המערכת שלכם), AR ייצר עבורכם עמודת id מסוג auto-increment (המימוש המדויק תלוי בבסיס הנתונים).
גם אם הגדרתם את ה primary key, (לדוגמה: עמודה בשם isbn) הגישה אליו בקוד הרובי תהייה דרך השם "id" ולא דרך השם המקורי של העמודה.
אם תפעילו את הפקודה t.timestamps (כמו בדוגמה למעלה), AR ייצר עבורכם 2 עמודות: created_at ו updated_at וינהל אותם עבור כל רשומה, כלומר: בכל עדכון של ערך של רשומה - יתעדכן גם ערך ה updated_at.
המודלים של AR הן מחלקות היורשות ממחלקת הבסיס ActiveRecord::Base, לדוגמה:
כפי שכבר הזכרנו - לא מציינים את השדות של המודל במחלקת המודל עצמה. בזמן עליה AR יתשאל את הסכמה של בסיס הנתונים ואז יוסיף את הפרמטרים ו getters/setters (כלומר: accessors) המתאימים בזמן ריצה. בעת הוספת עמודה חדשה בבסיס הנתונים - אין צורך בשינוי קוד במודל, ועדיין אפשר להשתמש בשדה החדש הזה - מה-Controller או ה View, למשל.
אז מה בכל מוגדר על המודל?
קשרים בין הטבלאות (associations)
ע"י פקודות הקשר:
validation
סיפקתי הקדמה על AR בפוסט על ריילס (כולל למשל, חוקי הקשר בין שמות מחלקות לשמות טבלאות בבסיס הנתונים) ולא אחזור על מידע זה.
AR הוא מימוש של דפוס עיצוב בשם זהה, שהופיע לראשונה בספר של מרטין פאוולר.
כל מחלקת מודל של AR מתארת טבלה בבסיס הנתונים, כאשר מופע של המחלקה מתאר מצביע לשורה מסוימת בטבלה (Row).
אובייקט של מודל AR הוא לא מבנה נתונים פשוט - זוהי מחלקה עם מתודות לכל דבר. המתודות יכולות להיות helpers לעבודה עם נתונים (למשל: calculated fields או find_matching_x), או business logic של ממש - כל עוד הלוגיקה נוגעת לרשומה הבודדת בבסיס הנתונים או מה שהיא מייצגת. לוגיקה הנוגעת בכמה אובייקטים במערכת - תשב במקומות אחרים במערכת (ב Controller או ב Lib).
אין אכיפה ממשית שכללים אלו באמת נשמרים ע״י המפתחים, וזה עניין של אחריות אישית והיכרות עם הכללים.
דפוס ה AR משנה במעט את כללי ה MVC ה״קלאסי״ (כי המודל כולל עכשיו גם לוגיקה), והוא זוכה על כך גם לביקורת:
- Uncle Bob טען שהמבנה של ActiveRecord מבלבל את הגבולות הברורים בארכיטקטורת האפליקציה.
- יש טענות על כך ש AR מקשה מאוד על ה Testability של המערכת.
- יש טענות שיצירת המודל בזמן ריצה וב Reflection מונע מכלים מסוימים לספק ערך לקוד המודל (למשל IDE).
טענות אלו נכונות, אך אלו הבחירות התכנוניות של ריילס - ויש להן גם יתרון בצד השני: פרודקטיביות פיתח.
בניגוד לחלק מכלי ה ORM (קיצור של Object-Relational Mapping) האחרים, AR לא מנסה ״להחביא לגמרי״ את ה SQL. הגישה היא יותר גישה של ״בואו נהפוך את השימוש ב SQL ליותר DRY".
למשל, AR, תחסוך לנו את העבודה המעצבנת ב SQL של לציין שוב ושוב את שמות השדות הרלוונטיים (חשבו למשל על Join מורכב). מצד שני היא כן רואה בשימוש במידה מסוימת של SQL כהכרחי, ולכן מספקת מתודות כגון find_by_sql בהן מזינים שאילתת SQL.
לאחר שנתקלתי שוב ושוב בצורך ״לעקוף את ה ORM״ בעבר - הגישה הזו נראית לי מאוזנת ובריאה. בעוד ששימוש ב SQL הוא לא דבר מומלץ ב Hibernate (כי אז ה caches של Hibernate לא יהיו מעודכנים, למשל), בריילס הנחת העבודה היא ש SQL יהיה בשימוש מפעם לפעם.
מה המחיר ש AR שילמה על זה? כנראה בביצועים, ובמגוון היכולות שיש לכלי ORM ואינם מפותחים כ"כ ב AR.
מחיר סביר, לטעמי.
AR, כמו ריילס, הוא כלי שנכתב בחשיבה ראשונית על אפליקציות CRUD (״מילוי טפסים והפקת דוחות״) ופחות לאפליקציות שמטפלות בלוגיקה מורכבת, או זקוקות לביצועים גבוהים.
כמו כל כלי ORM אחר - הביצועים ש AR תשיג הם אולי טובים יותר בממוצע מהביצועים של קוד שנכתב ללא חשיבה כלל על ביצועים, אך הם לא יוכלו להתחרות במפתח שמכוון לביצועים גבוהים.
סכמה
מודל (Model, של MVC) של AR היא מחלקה שיורשת ממחלקת הבסיס ActiveRecord::Base.
AR יצפה ששם המחלקה יופיע בצורת יחיד, ושם טבלה המתאימה - בצורת רבים (ע״פ החוקים שתיארתי בפוסט הקודם).
אין צורך להגדיר במחלקת המודל את העמודות השונות של הטבלה: בזמן ריצה AR יתשאל את בסיס הנתונים, ימצא את העמודות, ותוסיף שדות ו getters/setters לגישה אליהם על מחלקת המודל.
מדוע? בכדי למנוע מצבים של חוסר עקביות בין בסיס-הנתונים לקוד, ולחסוך תחזוקה כפולה של השדות הקיימים על כל טבלה (עקרון ה DRY).
מאיפה, אם כן, מגיעה הסכמה לבסיס הנתונים?
לפעמים אנו כותבים אפליקציה המכוונת לסכמה קיימת. אם לא, אז הדרך העיקרית בריילס לעשות זאת היא בעזרת קוד ריילס, בשם Migration.
בתיקיית ה db בפרויקט ריילס נמצא כמה קבצים הקשורים לעניין:
- קובץ ה schema.db הכולל תיאור של הסכמה השלמה.
- תיקיית migrate - בה יש ״סקריפטים״ שמעדכנים את הסכמה בבסיס הנתונים.
- קובץ ה seeds.rb.
באופן מעט לא-אינטואטיבי, אין לשנות את קובץ ה schema.rb. זהו קובץ שבעצמו הוא generated מתוך בסיס הנתונים, ונועד ליצירת סכמה מהירה ואמינה עבור התקנה חדשה של האפליקציה שלכם בבסיס נתונים חדש. הוא יכול להיות רפרנס טוב בכדי להבין את הסכמה בקלות.
ה״סקריפטים״ (מחלקות רובי) שבתיקיית ה migrate הן מה שמעדכן את הסכמה, והם מסודרים כך שיוכלו להעביר בסיס נתונים מ״מצב 5״ ל״מצב 6״ (שנוצר בעקבות שינויים במודל של האפליקציה), או לאחור מ ״מצב 6״ בחזרה ל״מצב 5״ (ככלי rollback).
את הסקריפטים האלו מריצים בעזרת פקודת rake db:migrate מה command line, בעוד שאת בניית הסכמה מחדש (על בסיס schema.rb) מפעילים בעזרת פקודת rake db:schema:load.
פקודות אלו נוגעות רק לסכמה. עבור הכנסת נתונים ראשוניים לבסיס הנתונים קיים הקובץ seeds.rb, שמופעל בפקודה rake db:seed.
פקודת rake db:setup, שנהוג להפעיל בהתקנת האפליקציה על מערכת חדשה, מפעילה בפועל גם db:create, גם db:schema:load ולבסוף את db:seed. ניתן לבחון את הסריפטים עצמם בגיטהאב.
בכדי לייצר migration חדש בד״כ משתמשים ב generator הבא:
$ bin/rails g migration <migration human-friendly name>
20150108083136_create_price_records.rb
הקובץ עצמו עשוי להראות כך:
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.decimal :price t.timestamps null: false end end end
change היא מתודת העבודה העיקרית. בתוכה נוכל לבצע שינויים בבסיס הנתונים כגון יצירת טבלה (כמו במקרה שלנו), הוספת או הרדת עמודה, או אינדקס, ועוד מספר פעולות. AR יידע להשתמש בתוכן המתודה בכדי לבצע את השינוי, וגם להחזיר אותו בחזרה למצב הקודם במקרה ונרצה לעשות מתישהו rollback (תקלות ב production, מישהו?).
יש מצבים בהם לא ניתן להסיק אוטומטית את הדרך חזרה, למשל: שינוי טיפוס של עמודה, או החלטה שמעתה לא יתקבלו nulls - בגלל שאין תשובה אחת לשאלה "מה לעשות עם הערכים הנוכחיים?". במקרים כאלה יש להשתמש בשתי מתודות אחרות: up (השינוי הרצוי) ו down (פעולת ה rollback) - והטיפול בשאלות הלא-ברורות.
AR מגדיר סט של כמה טיפוסי-ביניים בהן ניתן להשתמש, למשל: string, text, float, decimal, time, וכו׳
על כל עמודה ניתן להגדיר עוד properties, למשל null:false - עבור עמודה שנרצה שבסיס הנתונים יגן שלא תקבל ערך null.
בעזרת Adapter מתאים לכל בסיס נתונים, AR מחליט לאילו טיפוסים של בסיס הנתונים למפות את טיפוסי-הביניים שלו בפועל. למשל, האם text ישמר כ varchar, nvarchar, או CLOB. זהו סוג של שירות שאמור לחסוך למפתח את ההבנה העמוקה בין הטיפוסים השונים של בסיס הנתונים, ועבור רוב התסריטים - הבחירות שלו הן בהחלט טובות.
עבור בסיסי נתונים מסוימים, ה Adapter גם יתמוך בטיפוסים נוספים. למשל, אם אתם עובדים עם PostgreSQL, תוכלו להשתמש בטיפוסי AR בשם json או hstore או properties מסוימים - שיתמפו ליכולות של PostgreSQL.
AR ייצר getters ו setter על המודל עבור על עמודה, דרכם נוכל לגשת לנתונים.
- אם מדובר בשדה מסוג timestamp ה getter יחזיר אובייקט רובי מסוג Time.
- אם מדובר במספר עשרוני אז ה getter יחזיר אובייקט רובי מסוג BigDecimal (בכדי לא לאבד נתונים - בסיס הנתונים יכול לשמור דיוק גבוה מהיכולת של רובי). אם מדובר במספר עשרוני ללא ספרות עשרוניות לאחר הנקודה - יוחזר אובייקט רובי מסוג Fixnum (כלומר: "פרמיטיב" ה integer).
- אם מדובר בשדה בולאני, יווצר getter שסימן שאלה בסוף שמו - ע"פ הקונבנציה המקובלת ברובי.
- וכו'....
עמודות עם טיפול מיוחד
אם לא הגדרתם בעצמכם את ה primary key (מה שמומלץ רק במצב של טבלה שכבר קיימת לפני המערכת שלכם), AR ייצר עבורכם עמודת id מסוג auto-increment (המימוש המדויק תלוי בבסיס הנתונים).
גם אם הגדרתם את ה primary key, (לדוגמה: עמודה בשם isbn) הגישה אליו בקוד הרובי תהייה דרך השם "id" ולא דרך השם המקורי של העמודה.
אם תפעילו את הפקודה t.timestamps (כמו בדוגמה למעלה), AR ייצר עבורכם 2 עמודות: created_at ו updated_at וינהל אותם עבור כל רשומה, כלומר: בכל עדכון של ערך של רשומה - יתעדכן גם ערך ה updated_at.
המודל
המודלים של AR הן מחלקות היורשות ממחלקת הבסיס ActiveRecord::Base, לדוגמה:
class City < ActiveRecord::Base belongs_to :country has_many :streets_to_cities has_many :streets, :through=> :streets_to_cities def self.search_for_country(text) City.search( # Some complex search logic ) end end
כפי שכבר הזכרנו - לא מציינים את השדות של המודל במחלקת המודל עצמה. בזמן עליה AR יתשאל את הסכמה של בסיס הנתונים ואז יוסיף את הפרמטרים ו getters/setters (כלומר: accessors) המתאימים בזמן ריצה. בעת הוספת עמודה חדשה בבסיס הנתונים - אין צורך בשינוי קוד במודל, ועדיין אפשר להשתמש בשדה החדש הזה - מה-Controller או ה View, למשל.
אז מה בכל מוגדר על המודל?
קשרים בין הטבלאות (associations)
ע"י פקודות הקשר:
- belongs_to
- has_one :through ,has_one
- has_many :through ,has_many
- has_and_belongs_to_many
השימוש הנכון בפקודות הקשר דורשות מעט אימון. קיים תיעוד מקיף (עם תרשימים), אך הייתי רוצה להסביר כמה נקודות מבלבלות במיוחד:
ניתן לומר שספר has_one "תוכן עניינים", או להיהפך: ש"תוכן עניינים" belongs_to ספר. לכאורה זה סימטרי.
בפועל השאלה היא היכן נכון שינוהל ה foreign key בין הטבלאות?
בשימוש ב belongs_to הוא ינוהל על המודל שהגדיר את הקשר ("המקומי"), ובשימוש ב has_one הוא יוגדר על המודל האחר ("הרחוק").
פעמים רבות רוצים ניווטיות לשני הכיוונים, ואז מגדירים גם את belongs_to וגם את has_one, בשני המודלים במקביל.
כאשר אנו רוצים להגדיר קשר one-to-many, אזי אנו מגדירים אותו בשני הצדדים: נאמר גם שספר has_many דפים וגם שדף belongs_to ספר. שימו לב ששומרים על צורת היחיד והרבים כך שיתאמו לשפה הטבעית (pages:, אבל book:) :
בקשר של many-to_many מגדירים בשני הצדדים "<has_and_belongs_to_many :<other table".
הערה: AR מנהל את ה associations בעצמו. אם אתם רוצים שבסיס הנתונים יאכוף את תקינות ה foreign keys בנוסף ל AR, תוכלו להגדיר foreign keys על ה migration.
ניתן למצוא מידע על עוד אפשרויות בתיעוד של Associations
ניתן לומר שספר has_one "תוכן עניינים", או להיהפך: ש"תוכן עניינים" belongs_to ספר. לכאורה זה סימטרי.
בפועל השאלה היא היכן נכון שינוהל ה foreign key בין הטבלאות?
בשימוש ב belongs_to הוא ינוהל על המודל שהגדיר את הקשר ("המקומי"), ובשימוש ב has_one הוא יוגדר על המודל האחר ("הרחוק").
פעמים רבות רוצים ניווטיות לשני הכיוונים, ואז מגדירים גם את belongs_to וגם את has_one, בשני המודלים במקביל.
כאשר אנו רוצים להגדיר קשר one-to-many, אזי אנו מגדירים אותו בשני הצדדים: נאמר גם שספר has_many דפים וגם שדף belongs_to ספר. שימו לב ששומרים על צורת היחיד והרבים כך שיתאמו לשפה הטבעית (pages:, אבל book:) :
class Book < ActiveRecord::Base has_many :pages end class Page < ActiveRecord::Base belongs_to :book end
הערה: AR מנהל את ה associations בעצמו. אם אתם רוצים שבסיס הנתונים יאכוף את תקינות ה foreign keys בנוסף ל AR, תוכלו להגדיר foreign keys על ה migration.
ניתן למצוא מידע על עוד אפשרויות בתיעוד של Associations
validation
ע"י שימוש בשורה של פקודות ואלידציה כמו validate_presence_of או validates_numericality_of
Overriding Accessors
למשל: אתם רוצים לעשות formatting לערך השדה המגיע מבסיס הנתונים (getter) הוא להוסיף validation לא שגרתי או המרה של נתונים (setter).
Transient Model Members
לפעמים אתם רוצים שיהיו במודל שדות זמניים שלא יישמרו לבסיס הנתונים.
מגדירים אותם על המודל כמחלקת רובי רגילה (לרוב - בעזרת attr_accessors).
Scopes
שאילתות ביניים אותן ניתן להרחיב, רעיון דומה ל Views בבסיס הנתונים. פרטים בהמשך.
מתודות עזר שונות
שעוזרות לגשת לנתונים (כמו search_for_country בדוגמה למעלה) או כאלה שמבצעות business logic הקשור ל scope של המודל (אך לא יותר מכך!)
שמירה
עדכון המודל לא גורם לשמירה אוטומטית של הנתונים בבסיס הנתונים. יש לקרוא במפורש למתודת save.
מתודה יוצאת דופן היא create (יצירת row חדש) - שתבצע את השמירה בעצמה.
לינקים מעניינים:
http://blog.rubybestpractices.com/posts/gregory/055-issue-23-solid-design.html
Bypassing ActiveRecord for better performance
דרכים לעדכון מודל של AR
Transient Model Members
לפעמים אתם רוצים שיהיו במודל שדות זמניים שלא יישמרו לבסיס הנתונים.
מגדירים אותם על המודל כמחלקת רובי רגילה (לרוב - בעזרת attr_accessors).
Scopes
שאילתות ביניים אותן ניתן להרחיב, רעיון דומה ל Views בבסיס הנתונים. פרטים בהמשך.
מתודות עזר שונות
שעוזרות לגשת לנתונים (כמו search_for_country בדוגמה למעלה) או כאלה שמבצעות business logic הקשור ל scope של המודל (אך לא יותר מכך!)
שמירה
עדכון המודל לא גורם לשמירה אוטומטית של הנתונים בבסיס הנתונים. יש לקרוא במפורש למתודת save.
מתודה יוצאת דופן היא create (יצירת row חדש) - שתבצע את השמירה בעצמה.
יש שתי גרסאות של המתודות הנ"ל:
הדרך הפשוטה והבסיסית לשליפת רשומה ב AR היא בעזרת ה id (קרי: primary key):
דרך פופולרית נוספת היא לבצע דרך פונקציית ה where, שמקבלת תנאי WHERE של SQL:
AR ידאג לבצע escaping מתאים על הפרמטרים בכדי להגן בפני התקפת SQL Injection.
בקצה השני יש את מתודת find_by_sql שדורשת כפרמטר שאליתת SQL שלמה - ומחזירה תוצאה דומה. אין לה הגנות בפני SQL Injection, כמובן.
התוצאה של פעולת ה where היא אובייקט בשם ActiveRecord::Relation המכיל את כל הרשומות התואמות.
מלבד פעולות שליפת שורות כגון: first, all או to_a, מאפשר אובייקט ה Relation מאפשר לשרשר עוד תנאים (נקראים finder methods) לשאילתה. למשל:
עבור limit יש finder method אחות שעוזרת לעשות paging קל, בשם offset:
גרסה זו תחזיר את הספרים מספר 100-109 ששמם מתחיל ב "The", ממיונים ע"פ תאריך הפרסום בסדר יורד.
עוד finder method נפוצה היא joins המאפשרת להכתיב לשאילה לכלול טבלאות נוספות. בד"כ משתמשים בה כאשר כותבים לבד את ה SELECT:
an_order = Order.select("orders.customer_id, count(*) as total")
בניסיון להפוך את בניית השאילתה לרצף קריאות על אובייקטים - יש משהו מכשיל.
הנה שימוש בעייתי ב joins:
נתונה טבלת חברות, עם association לטבלת עובדים. בטבלת העובדים יש שדה שמציין אם העובד עדיין נמצא בחברה (active).
אנו רוצים לעשות שאילתה שתביא את רשימת החברות וכל העובדים הפעילים שלהן.
יותר מאוחר בקוד, בטבעיות, נבקש את שם העובדים.
מה קרה? השאילתה לא הביאה את שם העובדים (אין הרחבה של ה SELECT לכלול את employee.name).
AR מספק לנו "מציאות מדומיינת" של אובייקטים בזיכרון - ולכן אינו מונע מאיתנו לגשת ל person.name. הוא פשוט עושה SELECT נוסף בכל גישה ל name בכדי להביא את הנתון החסר. אבל... כאשר ניגשים ל person.name בלולאה - עשויות להיות הרבה מאוד שאילתות כאלה --> מה שכנראה יגרום לבעיית ביצועים משמעותית.
מה עושים?
ניתן לנסות ולזכור בכל פעם בקוד שניגשים לנתונים בצורה סדרתית לבדוק מה היה השאילתה שהביאה את הנתונים ולוודא שהיא יעילה. נניח: רוצים את שדה ה person.age? נלך ונעדכן שוב את השאילתה.
אפשר לעשות זאת בצורה מרכזית ע"י החלפת הפקודה joins בפקודה includes. פקודת includes פועלת כמו joins, אבל מוסיפה ל SELECT את כל ערכי שדות הטבלה שאילתה עשינו join לתוצאה - כך שיהיו זמינים לגישה ללא קריאה נוספת לבסיס הנתונים.
כפי שאתם מבינים - includes, בשימוש לא נכון, יכולה ליצור בעיית ביצועים בעצמה: אין טעם להשתמש בה כאשר עושים join לצורך פילטור הנתונים ואין כוונה להשתמש בשדות הטבלה האחרת. includes גם יכולה לגרום לבעיה אם הטבלה (או טבלאות) איתה אנו עושים join כוללת המון עמודות - הרבה נתונים שיעברו מבסיס הנתונים לזיכרון ולא יעשה בהם שימוש.
Scopes
תנאים המשורשרים של finder methods נוטים להתארך ולחזור על עצמם. AR מספק מנגנון של שימוש חוזר בהם בשם scopes.
AR מספק שורה של events לאורך מחזור החיים בהם אנו יכולים להתערב: לבצע validations מורכבים, למנוע ברגע האחרון עדכון נתונים לבסיס הנתונים, או לבצע שינויים במודל on-the-fly:
בנוסף יש עוד 2 callback:
ל callback אפשר להרשם בצורה דקלרטיבית, או בעזרת בלוק:
כמובן שצורת הבלוק מאפשרת לנו להוציא לוגיקה למקום משותף ולקרוא לה מכמה מודלים / מכמה שלבים שונים ב lifecycle.
כדי לעצור את ה Lifecycle ניתן לזרוק מתוך ה callback שגיאה מסוג ActiveRecord::Rollback. כל שגיאה אחרת תחלחל לשאר המערכת.
באירועי before_xxx, ניתן להחזיר את הערך false - בכדי להשיג תוצאה זהה.
הגבלת הניווט בין מודלים ע"פ חוק דמטר (Law of Demeter)
החוק של דמטר הוא החוק של "the least knowledge": התוכנה תהיה ניתנת יותר לתחזוקה אם כל מחלקה תדע כמה שפחות על מחלקות אחרות. הכלל הפרקטי ב AR הוא כלל "הנקודה האחת": אל תנווט בין מודלים מעבר לנקודה אחת.
נניח שיש לנו מערך מודלים: נהג מונית שייך לצי, ולצי יש חוזה.
אם נאפשר לעצמנו ניווט בלתי-מוגבל בין אובייקטים במודל נגיע בקרוב למצב שבו אנו קוראים בקוד לחוזה ממספר הולך וגדל של מקומות:
התוצאה תהיה שאנו רוצים לעשות שינוי באובייקט ה contract ופתאום מגלים עשרות מקומות בקוד שדורשים שינוי, מקומות שבכלל לא דמיינו שיהיו מודעים ל contract
שינוי עשרות שורות קוד היא בעיה לא-גדולה, אך הסיכוי לביצוע טעות באחד מעשרות שינויים - היא בעיה גדולה יותר. בעיה מספיק גדולה שתגרום לנו, פעמים רבות, לבצע שינוי פחות נכון - רק בכדי להימנע מהסיכון לרגרסיה בקוד. מכירים את המקרה?
ע"פ חוק הנקודה האחת, הקוד שלנו היה אמור להראות כך:
כאשר למודל fleet ולמודל driver יש "חסמי תלות" - מן getters שמחזירים לנו תשובה ללא הצורך להמשיך לנווט ולהיות תלויים בתלויות הפנימיות שלהם עצמם.
כתיבת ה getters הללו היא כמובן לא "DRY", ולשם כך ריילס מספקת פקודה בשם delegate שתקצר לנו את העבודה:
בעתיד, כאשר נרצה לעשות שינוי בקוד ולהביא את דמי הביטול לא מתוך חוזה, אלא מתוך חישוב אחד - נוכל לעשות שינוי רק במחלקה Fleet ע"י כתיבת getter בשם מתאים - והסרת ה delegete.
אם דמי הביטול יהיו דינאמיים לכל נהג - נוכל פשוט להוסיף getter בשם fleet_cancellation_fee על מודל הנהג - ולהסיר את ה delegation. שינוי במקום אחד וללא פחדים.
העיקרון הוא אותו עיקרון מאחורי השימוש ב getter ו setter - אבל הוא אפילו יותר שימושי: שינויים בקשרים במודל הם יותר נפוצים (ויותר כואבים לשינוי?) מאשר התסריט של הפיכת member במחלקה לערך מחושב - התסריט עליו getters/setter מגנים.
בסופו של דבר השאלה היא זו: כמה שליטה יש לכם בקוד? האם אתם מבצעים שינויים בקוד בצורה הנכונה ביותר, או נאצלים לעשות שינויים פחות נכונים בגלל חששות לרגרסיות בלתי רצויות?
כאשר נאלצים לעשות שינויים "עקומים" בקוד אנו מאשימים את אנשי ה product - שלא מסכימים "לשאת במחיר השינוי הנכון": שבוע עבודה וסכנה מסוימת לרגרסיות. "למה הם לא מוכנים להשקיע באיכות???" - אנחנו שואלים.
ובכן ידידי, הם לא מבינים למה שינוי קטן כפי שביקשו צריך להיות כ"כ מסובך - והרבה פעמים הם צודקים. אנחנו הם אלו שלא השקיעו באיכות במהלך הדרך - ודחינו את הבעיה עוד ועוד לעתיד: כאשר הרשינו לחלקים בקוד שלנו לפתח תלויות עמוקות זה בזה. עכשיו, זה מתפוצץ לנו בפנים - ואנו לא מסוגלים לבצע שינוי קטן בקלות. אז למה אנחנו מתפלאים שאחרים לא מוכנים לשלם את המחיר?
מקוצר זמן, אתאר את שני ה best-practices הבאים בקצרה בלבד:
ביצוע כל פעולות ה find מתוך המודל (ולא חס-ושלום מתוך ה View)
אפשר, ואולי נוח לבצע פעולות find על המודל מתוך ה View, כמו ב PHP או ASP של שנות ה-90! ;-)
יש בכך 2 בעיות:
שחרור לוגיקה שאיננה חלק מהמודל למחלקות משנה
ככל שמחלקת המודל תהיה גדולה יותר - יהיה קשה יותר לעקוב אחרי מה שהיא עושה. לא נדיר למצוא פעולות parsing בתוך המודל, למשל: to_json ו parse_json => סוג של מומחיות משנה של המודל.
למען הסדר הטוב, הוציאו קוד שאינו קשור ישירות למודל למחלקות-משנה (או module-משנה) של המודל. למשל:
טוב, סקרנו את ActiveRecord - בצורה שתאפשר לקבל תמונה טובה במה מדובר.
בפוסט הצלחתי לכסות רק חלקים מסך היכולות של AR: לא דיברנו על transactions, לא נכנסו לנבכי אפשרויות ה validation, ודילגנו על הרבה אפשרויות ותכונות הקיימות ב AR. AR הוא ותיק, ועשיר באפשרויות.
הערות יתקבלו בברכה.
שיהיה בהצלחה!
------ save - שתחזיר nil אם הייתה בעיה בעדכון הנתונים.
- !save -שתזרוק Error אם הייתה בעיה בעדכון הנתונים. כנ"ל לגבי !create.
ניווט וחיפוש
הדרך הפשוטה והבסיסית לשליפת רשומה ב AR היא בעזרת ה id (קרי: primary key):
a_book = Book.find(63114)
a_book = Book.where("name = 'The White Horse' and book_type = 'Fiction' ").first
ע"י צמצום השאילתה לתנאי ה WHERE בלבד, AR מספקת כוח רב תוך כדי "דילוג" על חלקים טכניים בשאילתת SQL (כמו בחירת הטבלה והעמודות שיחזרו, תוך כדי הימנעות מדו-משמעות).
בכדי להתגונן בפני חולשות של SQL Injection וגם מטעויות SQL, קיימת צורת שימוש מוגנת של הפונקציה where:
a_book = Book.where(name: 'The White Horse', book_type: 'Fiction')
AR ידאג לבצע escaping מתאים על הפרמטרים בכדי להגן בפני התקפת SQL Injection.
בקצה השני יש את מתודת find_by_sql שדורשת כפרמטר שאליתת SQL שלמה - ומחזירה תוצאה דומה. אין לה הגנות בפני SQL Injection, כמובן.
התוצאה של פעולת ה where היא אובייקט בשם ActiveRecord::Relation המכיל את כל הרשומות התואמות.
a_book = Book.where('name LIKE The%').order('publish_date DESC').limit(10)
עבור limit יש finder method אחות שעוזרת לעשות paging קל, בשם offset:
a_book = Book.where('name LIKE The%').order('publish_date DESC').limit(10).offset(100)
עוד finder method נפוצה היא joins המאפשרת להכתיב לשאילה לכלול טבלאות נוספות. בד"כ משתמשים בה כאשר כותבים לבד את ה SELECT:
an_order = Order.select("orders.customer_id, count(*) as total")
.group(:driver_id)
.joins(:customer)
.where(:'customer.type' => 'premium')
בניסיון להפוך את בניית השאילתה לרצף קריאות על אובייקטים - יש משהו מכשיל.
הנה שימוש בעייתי ב joins:
companies = Company.joins(:persons).where(:persons => { active: true } ).all # ... companies.each do |company| company.person.name endהסבר קצר:
נתונה טבלת חברות, עם association לטבלת עובדים. בטבלת העובדים יש שדה שמציין אם העובד עדיין נמצא בחברה (active).
אנו רוצים לעשות שאילתה שתביא את רשימת החברות וכל העובדים הפעילים שלהן.
יותר מאוחר בקוד, בטבעיות, נבקש את שם העובדים.
מה קרה? השאילתה לא הביאה את שם העובדים (אין הרחבה של ה SELECT לכלול את employee.name).
AR מספק לנו "מציאות מדומיינת" של אובייקטים בזיכרון - ולכן אינו מונע מאיתנו לגשת ל person.name. הוא פשוט עושה SELECT נוסף בכל גישה ל name בכדי להביא את הנתון החסר. אבל... כאשר ניגשים ל person.name בלולאה - עשויות להיות הרבה מאוד שאילתות כאלה --> מה שכנראה יגרום לבעיית ביצועים משמעותית.
מה עושים?
ניתן לנסות ולזכור בכל פעם בקוד שניגשים לנתונים בצורה סדרתית לבדוק מה היה השאילתה שהביאה את הנתונים ולוודא שהיא יעילה. נניח: רוצים את שדה ה person.age? נלך ונעדכן שוב את השאילתה.
אפשר לעשות זאת בצורה מרכזית ע"י החלפת הפקודה joins בפקודה includes. פקודת includes פועלת כמו joins, אבל מוסיפה ל SELECT את כל ערכי שדות הטבלה שאילתה עשינו join לתוצאה - כך שיהיו זמינים לגישה ללא קריאה נוספת לבסיס הנתונים.
כפי שאתם מבינים - includes, בשימוש לא נכון, יכולה ליצור בעיית ביצועים בעצמה: אין טעם להשתמש בה כאשר עושים join לצורך פילטור הנתונים ואין כוונה להשתמש בשדות הטבלה האחרת. includes גם יכולה לגרום לבעיה אם הטבלה (או טבלאות) איתה אנו עושים join כוללת המון עמודות - הרבה נתונים שיעברו מבסיס הנתונים לזיכרון ולא יעשה בהם שימוש.
Scopes
תנאים המשורשרים של finder methods נוטים להתארך ולחזור על עצמם. AR מספק מנגנון של שימוש חוזר בהם בשם scopes.
class Order < ActiveRecord::Base scope :created_today, -> { where('created_at >= ?', Time.zone.now.beginning_of_day) } end todays_biggest_invoices = Order.created_today.order('amount DESC').limit(25) invoices_to_handle = Order.created_today.where(status: open) invoices_to_handle = Order.where(status: open).created_today # also valid
מחזור-החיים של מודל
AR מספק שורה של events לאורך מחזור החיים בהם אנו יכולים להתערב: לבצע validations מורכבים, למנוע ברגע האחרון עדכון נתונים לבסיס הנתונים, או לבצע שינויים במודל on-the-fly:
בנוסף יש עוד 2 callback:
- after_initialize - מיד לאחר יצירה של כל מופע של המודל
- after_find - מיד לאחר כל פעולת find
ל callback אפשר להרשם בצורה דקלרטיבית, או בעזרת בלוק:
class CreditCard < ActiveRecord::Base belongs_to :person after_validation :do_after_validation before_validation(on: :create) do self.number = number.gsub(/[^0-9]/, '') if attribute_present?('number') end protected def do_after_validation log.write('something') end endהפרמטר on: :create מאפשר לי לבצע את הקוד רק לפני validation של רשומה חדשה (פעולות create ולא update).
כמובן שצורת הבלוק מאפשרת לנו להוציא לוגיקה למקום משותף ולקרוא לה מכמה מודלים / מכמה שלבים שונים ב lifecycle.
כדי לעצור את ה Lifecycle ניתן לזרוק מתוך ה callback שגיאה מסוג ActiveRecord::Rollback. כל שגיאה אחרת תחלחל לשאר המערכת.
באירועי before_xxx, ניתן להחזיר את הערך false - בכדי להשיג תוצאה זהה.
Best practices
הגבלת הניווט בין מודלים ע"פ חוק דמטר (Law of Demeter)
החוק של דמטר הוא החוק של "the least knowledge": התוכנה תהיה ניתנת יותר לתחזוקה אם כל מחלקה תדע כמה שפחות על מחלקות אחרות. הכלל הפרקטי ב AR הוא כלל "הנקודה האחת": אל תנווט בין מודלים מעבר לנקודה אחת.
נניח שיש לנו מערך מודלים: נהג מונית שייך לצי, ולצי יש חוזה.
אם נאפשר לעצמנו ניווט בלתי-מוגבל בין אובייקטים במודל נגיע בקרוב למצב שבו אנו קוראים בקוד לחוזה ממספר הולך וגדל של מקומות:
<%= @driver.fleet.contract.overtime_rate ... %>
...
foo(driver.fleet.contract.cancellation_fee, ....)
שינוי עשרות שורות קוד היא בעיה לא-גדולה, אך הסיכוי לביצוע טעות באחד מעשרות שינויים - היא בעיה גדולה יותר. בעיה מספיק גדולה שתגרום לנו, פעמים רבות, לבצע שינוי פחות נכון - רק בכדי להימנע מהסיכון לרגרסיה בקוד. מכירים את המקרה?
ע"פ חוק הנקודה האחת, הקוד שלנו היה אמור להראות כך:
<%= @driver.fleet_contract_overtime_rate ... %>
...
foo(driver.fleet_cancellation_fee, ....)
כאשר למודל fleet ולמודל driver יש "חסמי תלות" - מן getters שמחזירים לנו תשובה ללא הצורך להמשיך לנווט ולהיות תלויים בתלויות הפנימיות שלהם עצמם.
כתיבת ה getters הללו היא כמובן לא "DRY", ולשם כך ריילס מספקת פקודה בשם delegate שתקצר לנו את העבודה:
class Driver < ActiveRecord::Base belongs_to :fleet delegate :overtime_rate, :cancellation_fee, :to => :Fleet, :prefix => true end class Fleet < ActiveRecord::Base has_many :drivers has_one :contract delegate :overtime_rate, :cancellation_fee, :to => :Contract end class Contract < ActiveRecord::Base belongs_to :fleet endמשמעות השימוש ב delegate בדומה לעיל היא כזו:
- אם מבקשים מ driver את דמי הביטול - העבר את הבקשה ל Fleet.
- אם מבקשים מה Fleet את דמי הביטול - העבר את הבקשה ל Contract.
כאשר ברמת ה Driver אנו מוסיפים את ה prefix עם שם ה delegate בגישה לשדות - עבור הקריאות / בגלל הקונבנציה.
בעתיד, כאשר נרצה לעשות שינוי בקוד ולהביא את דמי הביטול לא מתוך חוזה, אלא מתוך חישוב אחד - נוכל לעשות שינוי רק במחלקה Fleet ע"י כתיבת getter בשם מתאים - והסרת ה delegete.
אם דמי הביטול יהיו דינאמיים לכל נהג - נוכל פשוט להוסיף getter בשם fleet_cancellation_fee על מודל הנהג - ולהסיר את ה delegation. שינוי במקום אחד וללא פחדים.
העיקרון הוא אותו עיקרון מאחורי השימוש ב getter ו setter - אבל הוא אפילו יותר שימושי: שינויים בקשרים במודל הם יותר נפוצים (ויותר כואבים לשינוי?) מאשר התסריט של הפיכת member במחלקה לערך מחושב - התסריט עליו getters/setter מגנים.
בסופו של דבר השאלה היא זו: כמה שליטה יש לכם בקוד? האם אתם מבצעים שינויים בקוד בצורה הנכונה ביותר, או נאצלים לעשות שינויים פחות נכונים בגלל חששות לרגרסיות בלתי רצויות?
כאשר נאלצים לעשות שינויים "עקומים" בקוד אנו מאשימים את אנשי ה product - שלא מסכימים "לשאת במחיר השינוי הנכון": שבוע עבודה וסכנה מסוימת לרגרסיות. "למה הם לא מוכנים להשקיע באיכות???" - אנחנו שואלים.
ובכן ידידי, הם לא מבינים למה שינוי קטן כפי שביקשו צריך להיות כ"כ מסובך - והרבה פעמים הם צודקים. אנחנו הם אלו שלא השקיעו באיכות במהלך הדרך - ודחינו את הבעיה עוד ועוד לעתיד: כאשר הרשינו לחלקים בקוד שלנו לפתח תלויות עמוקות זה בזה. עכשיו, זה מתפוצץ לנו בפנים - ואנו לא מסוגלים לבצע שינוי קטן בקלות. אז למה אנחנו מתפלאים שאחרים לא מוכנים לשלם את המחיר?
מקוצר זמן, אתאר את שני ה best-practices הבאים בקצרה בלבד:
ביצוע כל פעולות ה find מתוך המודל (ולא חס-ושלום מתוך ה View)
אפשר, ואולי נוח לבצע פעולות find על המודל מתוך ה View, כמו ב PHP או ASP של שנות ה-90! ;-)
יש בכך 2 בעיות:
- סבירות גבוהה לשכפול קוד - כי כמה Views זקוקים לאותו חיפוש.
- קשה להרכיב תמונה ברורה של הגישות לבסיס הנתונים. כאשר רוצים לעשות שינויים במודל - לא ברור אילו השפעות יהיו לו, כי הקוד הרלוונטי "מפוזר" ברחבי המערכת וקשה למצוא את כולו.
התוצאה - נטיה להעדיף שינויים פחות מסוכנים, אך גם פחות טובים. "אולי נכתוב trigger בבסיס הנתונים - וגמרנו?"
נכון, אפשר להעביר את פעולות ה find ל controller ולקבל 90% מהתמורה. לוגיקת הגישה לבסיס הנתונים עכשיו מפוזרת על 2 מחלקות בלבד. אבל למה לא לחסוך את הצעד הקטן הנוסף?? פשוט שימו את כל לוגיקת הגישה לבסיס הנתונים במודל - וחסכו בלבולים וחוסרי הבנות.
שחרור לוגיקה שאיננה חלק מהמודל למחלקות משנה
ככל שמחלקת המודל תהיה גדולה יותר - יהיה קשה יותר לעקוב אחרי מה שהיא עושה. לא נדיר למצוא פעולות parsing בתוך המודל, למשל: to_json ו parse_json => סוג של מומחיות משנה של המודל.
למען הסדר הטוב, הוציאו קוד שאינו קשור ישירות למודל למחלקות-משנה (או module-משנה) של המודל. למשל:
- לוגיקת parsing / serialization. יתרון נוסף - תוכלו לבדוק (בדיקות-יחידה) את הקוד הזה בקלות.
- finders - אם יש הרבה.
הכל במידה, כמובן. אם יש מתודת parsing אחת באורך 4 שורות - זה יהיה כנראה מיותר להוציא אותה החוצה.
סיכום
טוב, סקרנו את ActiveRecord - בצורה שתאפשר לקבל תמונה טובה במה מדובר.
בפוסט הצלחתי לכסות רק חלקים מסך היכולות של AR: לא דיברנו על transactions, לא נכנסו לנבכי אפשרויות ה validation, ודילגנו על הרבה אפשרויות ותכונות הקיימות ב AR. AR הוא ותיק, ועשיר באפשרויות.
הערות יתקבלו בברכה.
שיהיה בהצלחה!
לינקים מעניינים:
http://blog.rubybestpractices.com/posts/gregory/055-issue-23-solid-design.html
Bypassing ActiveRecord for better performance
דרכים לעדכון מודל של AR
אין תגובות:
הוסף רשומת תגובה