ruby on rails 103 Active Record Validations : نظرة عامة


Muhammad Ashraf

يوضح لك هذا الدليل كيفية التأكد من صحة وضع الكائنات Objects قبل دخولها فى قاعدة البيانات ، باستخدام خاصية تصديقات Active Record.

1 نظرة عامة على التصديقات

مثال لعملية تصديق بسيطة :

class Person < ApplicationRecord
  validates :name, presence: true
end

Person.create(name: "John Doe").valid? # => true
Person.create(name: nil).valid? # => false

كما ترى في المثال ، يُعلِمُنا استخدام خاصية التصديق بأن ” Person ” غير ساري بدون خاصية الإسم. وكذلك Person الآخر لن يتم تثبيته فى قاعدة البيانات.
قبل التعمق أكثر في التفاصيل ، دعنا نتكلم أولا عن كيفية ملائمة التصديقات في الصورة الكبيرة لتطبيقك.

1.1لماذا نستخدم التصديقات؟

تُستخدم التصديقات/التحقيقات للتأكد من أن البيانات الصالحة للاستخدام وحدها التي سيتم حفظها فى قاعدة البيانات. على سبيل المثال: يمكن أن يكون مهم لتطبيقك ضمان إدخال كل مستخدم لعنوان بريد إلكتروني و عنوان بريدي صالح للاستخدام. التحقيقات التي تكون على المستوى النموذجي Model-level Validations هى الطريقة الأمثل لضمان حفظ البيانات السارية وحدها بقاعدة بياناتك. إنها قابلة للتشغيل المتبادل على قواعد البيانات ، حيث لايمكن للمستخدم تجاوزها أو التحايل عليها من أي مستخدم ، و مناسبة للاختبار و التعامل المستمر. Rails تجعلها سهلة الاستخدام ، توفّر مساعد مدمج للاستخدامات الشائعة ، و تسمح لك بصناعة طرق التحقق الخاصة بك أيضًا.

هناك العديد من الطرق للتحقق من صحة البيانات قبل حفظها فى قاعدة البيانات، بما فى ذلك بعض القيود المرتبطة أساسًا بقاعدة البيانات، تصديقات من جانب العميل client-side validations ، و تصديقات على مستوى التحكم controller-level validation.

إليك ملخّص السلبيّات و الإيجابيّات:

  • قيود قواعد البيّانات و/أو الإجراءات المخزّنة تجعل آليّات التحقيق معتمدة على قاعدة البيّانات ، و يمكن أن تجعل الإختبار و الصيانة أكثر صعوبة. مع ذلك ، لو كانت قاعدة البيانات الخاصة بك تستخدم بواسطة تطبيقات أخرى ، فقد تكون فكرة جيدة أن تستخدم بعض القيود على مستوى قاعدة البيّانات. بالإضافة إلى ذلك، التصديقات التي تكون على مستوى قاعدة البيانات يمكن أن تتعامل بأمان مع بعض الأشياء التي يصعب تطبيقها بالطرق الأخرى (مثل التميز/التفرّد فى الجداول المستخدمة بكثرة).
  • يمكن للتحقيقات التي تكون من جهة العميل مفيدة ، لكنها بشكل عام لا يُعتَمد عليها اذا تم استخدامها وحدها. إذا تم تنفيذها باستخدام JavaScript يمكن تجاوزها إذا كانت JavaScript غير مفعّلة فى متصفّح المستخدم. مع ذلك ، اذا تم دمجها مع تقنيّات أخرى يمكن أن تكون هذه التحقيقات طريقة مناسبة لتوفير ردود أفعال لمستخدمي موقعك.
  • Controller-level validations يمكن أن تكون مغرية للاستعمال ، لكن في الغالب تصبح غير عمليّة و صعبة فى الاختبار و الصيانة. من الجيد أن تجعل متحكماتك صغيرة ، حيث ستجعل تطبيقك محبب للاستخدام على المدى الطويل.
    قم بالإختيار مما سبق فى بعض الحالات التي تراها مُناسبة. لكن رأى فريق Rails أن model-level validations هي الأكثر تناسبًا لجميع الظروف.

1.2لماذا يحدث التحقيق؟

هناك نوعان من كائنات Active Record: تلك التى تتوافق مع صف بداخل قاعدة بياناتك ، و تلك التى لا تتوافق. عندما تنشىء كائن جديد – باستخدام طريقة new على سبيل المثال - هذا الكائن لا ينتمى لقاعدة البيانات حتّى اللحظة. ما إن تقوم باستدعاء save لهذا الكائن سيتم حفظه في الجدول المناسب بقاعدة البيانات. يستخدم Active Record طريقة new_record? لتحديد إذا ما كان الكائن موجود في قاعدة البيانات أم لا. فكّر في فئة Active Record التالية:

class Person < ApplicationRecord
end

يمكننا ملاحظة أنها تعمل بالنظر إلى ناتج rails console:

$ bin/rails console
>> p = Person.new(name: "John Doe")
=> #<Person id: nil, name: "John Doe", created_at: nil, updated_at: nil>
>> p.new_record?
=> true
>> p.save
=> true
>> p.new_record?
=> false

إن إنشاء و حفظ سجل جديد سوف يرسل عمليّة SQL INSERT إلى قاعدة البيانات. تحديث سجل موجود سوف يرسل عملية SQL UPDATE بدلًا من ذلك. التحقيقات تُجرى عادةً قبل إرسال هذه الأوامر إلى قاعدة البيانات. في حين فشل أي تحقيق سيتم تحديد الكائن “غير صالح” و لن ينفّذ Active Record عمليات الإدخال أو التحديث. يتجنّب هذا تخزين كائنات غير سارية في قاعدة البيانات. يمكنك أيضًا اختيار إجراء تحقيقات معينة عند إنشاء وحفظ أو تحديث كائن.

Quote

هناك طرق كثيرة لتغيير حالة الكائن في قاعدة البيانات. سوف تنشّط بعض الطرق التحقيقات ، لكن بعضها لن يفعل ذلك. هذا يعني أنه من الممكن أن يتم حفظ كائن بقاعدة البيانات في حالة غير صالحة إذا لم تكن حذرًا.

الطرق التالية تُشغل التحقيقات و سوف تحفظ الكائنات في قاعدة البيانات فقط إذا كانت صالحة للاستخدام:

  • create
  • create!
  • save
  • save!
  • update
  • update!

الأوامر التى تنتهي بـ ! bang versions ( save! على سبيل المثال) تقوم بعمل استثناء فى حالة عدم صحة السجل. الآخرون لا يفعلون ذلك. Save و update يُخرجوا false خطأً ، و create تُعيد نفس الكائن.

1.3 تخطّى التحقيقات

الدوال التالية تتخطى التحقيقات و تحفظ الكائن فى قاعدة البيانات بغض النظر عن صحّته. لذلك يجب استخدامها بحذر.

  • decrement!
  • decrement_counter
  • increment!
  • increment_counter
  • toggle!
  • touch
  • update_all
  • update_attribute
  • update_column
  • update_columns
  • update_counters

لاحظ أن save لديها القدرة على تخطي التحقيقات إذا تم إلحاقها بالأمر validate: false. هذه الطريقة أيضًا يجب استخدامها بحرص.

  • save(validate: false)

1.4 Valid? و invalid? >> صالح؟ و غيرصالح؟

قبل حفظ كائن في Active Record ، يجري Rails تحقيقاتك. لو كانت هذه التحقيقات تخرج أخطاء ، لا يقوم Rails بحفظ الكائن.

يمكنك أيضًا إجراء هذه التحقيقات بنفسك. Valid? ينشّط تحقيقاتك و يرد بـ true (صحيح) إذا لم يكن هناك أخطاء. و false (خطأ) فيما عدا ذلك. كما رأيت بالأعلى:

class Person < ApplicationRecord
  validates :name, presence: true
end

Person.create(name: "John Doe").valid? # => true
Person.create(name: nil).valid? # => false

بعد إجراء Active Record لتحقيقاتك، يمكن الوصول لأي خطأ من خلال وسيلة errors.messages التي ترد بمجموعة من الأخطاء. كما هي معرّفة ، الكائن صالح للاستخدام إذا كان تجمع الأخطاء هذا فارغًا بعد إجراء التحقيقات. لاحظ أن الكائن الممثل بـ new لن يبلغ عن أخطاء حتى لو كان غير صالح تقنيًّا؛ لأن التحقيقات تُجرى تلقائيّا عندما يتم حفظ الكائن ، كما هوالحال مع دوال create و save.

class Person < ApplicationRecord
  validates :name, presence: true
end

>> p = Person.new
# => #<Person id: nil, name: nil>
>> p.errors.messages
# => {}

>> p.valid?
# => false
>> p.errors.messages
# => {name:["can't be blank"]}

>> p = Person.create
# => #<Person id: nil, name: nil>
>> p.errors.messages
# => {name:["can't be blank"]}

>> p.save
# => false

>> p.save!
# => ActiveRecord::RecordInvalid: Validation failed: Name can't be blank

>> Person.create!
# => ActiveRecord::RecordInvalid: Validation failed: Name can't be blank

Invalid? هي ببساطة عكس valid?. تقوم بإجراء التحقيقات و ترد بـ true إذا وُجِدَ أي خطأ ، و false إذا لم تتواجد أيّة أخطاء.

1.5 errors[] (الأخطاء)

لكي تتأكد ما اذا كانت خاصّية معينة لكائن سارية أم لا يمكنك استخدام errors [ : attribute]. تقوم بالرد بمصفوفة array بكل الأخطاء للخاصيّة. إذا لم يكن هناك أخطاء للخاصية المحددة يتم الرد بمصفوفة فارغة.
تكون تلك الطريقة مفيدة بعدما تُجرى التحقيقات فقط ؛ لأنها تقوم بفحص مجموعات الأخطاء فقط ولا تنشّط التحقيقات بنفسها. إنها تختلف عن طريقة ActiveRecord : : Base#invalid? المشروحة بالأعلى ؛ لأنها لا تؤكّد صحّة الكائن ككل. إنها تقوم فقط بفحص إذا وُجد أخطاء بخاصيّة واحدة بالكائن.

class Person < ApplicationRecord
  validates :name, presence: true
end

>> Person.new.errors[:name].any? # => false
>> Person.create.errors[:name].any? # => true

1.6 errors.details تفاصيل الأخطاء

لكي تكشف أي تحقيقات فشلت فى خاصية معيّنة يمكنك استخدام errors.details [ : attribute ]. تقوم بالرد بمصفوفة من الـ hashes مع مفتاح : error للحصول على رمز المصادقة:

class Person < ApplicationRecord
  validates :name, presence: true
end

>> person = Person.new
>> person.valid?
>> person.errors.details[:name] # => [{error: :blank}]

المصدر:
توثيقات Ruby on Rails.





تفاعل الأعضاء


لا توجد أيّة تعليقات بعد



يجب أن تكون عضوًا لدينا لتتمكّن من التعليق

انشاء حساب جديد

يستغرق التسجيل بضع ثوان فقط


سجّل حسابًا جديدًا

تسجيل الدخول

تملك حسابا مسجّلا بالفعل؟


سجّل دخولك الآن