• save – שתחזיר nil אם הייתה בעיה בעדכון הנתונים.
• !save -שתזרוק Error אם הייתה בעיה בעדכון הנתונים. כנ\"ל לגבי !create.

ניווט וחיפוש

הדרך הפשוטה והבסיסית לשליפת רשומה ב 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:

בניסיון להפוך את בניית השאילתה לרצף קריאות על אובייקטים – יש משהו מכשיל.

הנה שימוש בעייתי ב 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 הוא כלל \"הנקודה האחת\": אל תנווט בין מודלים מעבר לנקודה אחת.

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

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

ע\"פ חוק הנקודה האחת, הקוד שלנו היה אמור להראות כך:

כאשר למודל 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.

בעתיד, כאשר נרצה לעשות שינוי בקוד ולהביא את דמי הביטול לא מתוך חוזה, אלא מתוך חישוב אחד – נוכל לעשות שינוי רק במחלקה 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 זקוקים לאותו חיפוש.
• קשה להרכיב תמונה ברורה של הגישות לבסיס הנתונים. כאשר רוצים לעשות שינויים במודל – לא ברור אילו השפעות יהיו לו, כי הקוד הרלוונטי \"מפוזר\" ברחבי המערכת וקשה למצוא את כולו. 

שחרור לוגיקה שאיננה חלק מהמודל למחלקות משנה

ככל שמחלקת המודל תהיה גדולה יותר – יהיה קשה יותר לעקוב אחרי מה שהיא עושה. לא נדיר למצוא פעולות parsing בתוך המודל, למשל: to_json  ו parse_json => סוג של מומחיות משנה של המודל.

למען הסדר הטוב, הוציאו קוד שאינו קשור ישירות למודל למחלקות-משנה (או module-משנה) של המודל. למשל:

• לוגיקת parsing / serialization. יתרון נוסף – תוכלו לבדוק (בדיקות-יחידה) את הקוד הזה בקלות.
• finders – אם יש הרבה.

סיכום

טוב, סקרנו את ActiveRecord – בצורה שתאפשר לקבל תמונה טובה במה מדובר.
בפוסט הצלחתי לכסות רק חלקים מסך היכולות של AR: לא דיברנו על transactions, לא נכנסו לנבכי אפשרויות ה validation, ודילגנו על הרבה אפשרויות ותכונות הקיימות ב AR. AR הוא ותיק, ועשיר באפשרויות.

הערות יתקבלו בברכה.

שיהיה בהצלחה!