البحث في الموقع

في الدروس السابقة ألقينا نظرة عامة على تهجير Active Record وكيفية إنشائه كما وتعلمنا أوامر التهجير وسنتابع في هذا الدرس ما بقي من هذه السلسلة التعليمية حول تهجير Active Record. 4 تشغيل التهجير Running Migration Rails توفر مجموعة من مهام bin/rails لتشغيل مجموعة التهجيرات التي تريدها. إن أول مهام التهجير bin/rails التي ستستعملها سيكون غالبًا rails db:migrate. و هذا هو أبسط صور التهجير حيث يقوم بتشغيل دوال change و up لكل التهجيرات التي لم تقم بتشغيلها بعد. و سيقوم بالإغلاق إن لم يُكن لديك تهجيرات من هذا النوع. عدا ذلك سيقوم بتشغيل التهجيرات بالترتيب طبقًا لتوقيته. لاحظ أن تشغيل أمر db:migrate سيقوم بتشغيل الأمر db:schema:dump و هذا سوف يقوم بتحديث ملف db/schema.rb ليوافق تركيب قاعدة بياناتك. إذا قُمت بتحديد نُسخة version معينة، فإن Active Record سيقوم بعمل التهجيرات اللازمة (باستخدام دوال change و up و down) حتى يصل للنسخة المرغوبة. يُعبر عن النسخة باستخدام أرقام توضع في إسم ملف التهجير، فإذا أردت أن تقوم بالتهجير لنُسخة 20080906120000 قُم بتشغيل: $ bin/rails db:migrate VERSION=20080906120000 إذا كانت النُسخة المرغوبة تحمل رقم أعلى من الرقم السابق فإن التهجير سيقوم بتشغيل دوال change أو up. و يقوم بعمل التهجيرات حتى يصل إلى رقم النُسخة المرغوبة. أما إذا كانت النسخة المرغوبة تحمل رقمًا أعلى فإن التهجير سيقوم بتشغيل دالة down حتى تصل إلى رقم النُسخة، لكنه لن يقوم بعمل تهجير لها(لأن ذلك سيؤدي إلى نُسخة أقل من المرغوبة). 4.1 العودة للوراء باستخدام rollback سيتحتم عليك أحيانًا العودة بالتهجير للوراء (لاحظ الفرق بينه و بين العكس). مثال: إذا أردت أن تقوم بتصحيح خطأ قُمت به، فبدلًا من تتبع رقم النُسخة المرتبطة بذلك التهجير، يُمكنك تشغيل هذا الكود: $ bin/rails db:rollback إن أمر rollback سيقوم بعكس دالة change أو تشغيل دالة down. أما إذا أردت أن تعود لأكثر من تهجير يُمكنك تحديد عدد المرات التي ستعمل فيها الدالة rollback عن طريق STEP. مثال: $ bin/rails db:rollback STEP=3 هذا سوف يعكس 3 تهجيرات. إن أمر db:migrate:redo يُعتبر إختصار لأمر rollback و لكنه سيعود بك لنقطة البداية مُجددًا. و يُمكنك تعيين عدد الخطوات به أيضًا باستخدام STEP، مثال: $ bin/rails db:migrate:redo STEP=3 إن دالة db:migrate يُمكنها أي شيئ تقوم به أوامر bin/rails ولكنهم أكثر مُلائمة عندما لا تحتاج لتحديد النُسخة التي تعمل عليها بدقة. 4.2 تهيئة قاعدة البيانات Setup Database أمر rails db:setup سيقوم بصنع قاعدة البيانات و تحميل الإسكيما و تزويدها ببياناتها الأولية. 4.3 إعادة تهيئة قاعدة البيانات Resetting Database لإعادة التهيئة استخدم أمر rails db:reset ثم قُم باستعمال أمر التهيئة من جديد. و هذان الأمران يُمكن استبدالهما بدالة rails db:drop db:setup 4.4 تشغيل تهجيرات محددة Running Specific Migrations إذا كُنت تريد إجراء عملية تهجير محددة سواء للأمام up أو للخلف down. فيُمكنك إستخدام أمر db:migrate:up أو db:migrate:down و لكن سيتوجب عليك تحديد تعيين رقم نُسخة التهجير الذي ترغب بعمله، مثال: $ bin/rails db:migrate:up VERSION=20080906120000 في المثال السابق سيقوم Active Record بالتأكد من وجود هذا التهجير مُسبقًا أم لا. فإن لم يكن موجودًا من قبل فسيقوم بتشغيل دالة change أو دالة up. أما إذا كان موجودًا بالفعل فلن يقوم بشيء. 4.5 تشغيل التهجير في بيئات عمل مختلفة different environments تلقائيًا يتم تشغيل bin/rails db:migrate في بيئة development. ويُمكنك استعمال هذا الأمر RAILS_ENV لتحديد بيئة العمل التي ترغب بعمل التهجير عليها، في الكود التالي سنقوم بعمل التهجيرات على بيئة test: $ bin/rails db:migrate RAILS_ENV=test 4.6 تغيير ناتج (خارج – Output) التهجير إن التهجير تلقائيًا يقوم بإخبارك بالمهام التي يفعلها و الوقت الذي قد يأخذه، فإذا قُمت باستخدام تهجير لصنع جدول أو إضافة قاموس، فإن الناتج سيكون هكذا: == CreateProducts: migrating ================================================= -- create_table(:products) -> 0.0028s == CreateProducts: migrated (0.0028s) ======================================== و هُناك العديد من الدوال المتوفرة داخل ملفات التهجير تساعد بمعرفة هذا الأمر: الدالة غرضها suppress_message يقوم بتحديد جزء من الكود block و يقوم بإخراج رسالة تحتوي على ما بهذا الكود. say يقوم هذا الأمر بحفظ نص رسالة و تقديمها كما هي. و سيقوم مُتغير من نوع Boolean بتحديد ظهور الرسالة من عدمه say_with_time يقوم بتحديد وقت مُعين لظهور الرسالة، و إذا كان الكود المكتوب يُخرج رقم integer فإنه يُعامله على أنه عدد الصفوف المُتأثرة. على سبيل المثال، فإن هذا التهجير: class CreateProducts < ActiveRecord::Migration[5.0] def change suppress_messages do create_table :products do |t| t.string :name t.text :description t.timestamps end end say "Created a table" suppress_messages {add_index :products, :name} say "and an index!", true say_with_time 'Waiting for a while' do sleep 10 250 end end end سوف يُنتج هذه المُخرجات == CreateProducts: migrating ================================================= -- Created a table -> and an index! -- Waiting for a while -> 10.0013s -> 250 rows == CreateProducts: migrated (10.0054s) ======================================= أما إذا أردت من Active Record ألا يُخرج أي شيئ فيُمكنك استخدام أمر rails db:migrate VERBOSE=false 5 تغيير التهجيرات الموجودة مُسبقًا إذا قُمت بارتكاب خطأ ما أثناء كتابتك للتهجير، و قُمت بتشغيل التهجير. فلا يُمكنك تعديل التهجير ثًم تشغيله من جديد. لأن Rails لن تفعل شيئًا عند كتابة الأمر rails eb:migrate لأنك بالفعل قُمت بتشغيله من قبل. لذلك عليك استخدام أمر العودة rollback بكتابة bin/rails db:rollback ثُم تعديل التهجير ثُم تشغيله من جديد. بوجه عام، تعديل التهجيرات السابقة ليس أمرًا جيدًا، لأنه سيتسبب لك بالكثير من العمل، أنت و من يعملون معك على قاعدة البيانات. خصيصًا إن تم تشغيل هذا التهجير على أجهزة السيرفرات بالفعل. فبدلًا من عمل ذلك يُمكنك كتابة تهجير جديد وظيفته هي تغيير الأخطاء أو عمل التعديلات اللازمة. فإن تعديل تهجير مكتوب حديثًا أسهل من تعديل تهجير تم تشغيله على الأجهزة فعلًا. يُمكنك إستخدام أمر العاكس revert الذي تحدثنا عنه هُنا مُسبقًا. 6 إهمال الإسكيما Schema Dumping 6.1 ماهي ملفات الإسكيما؟ إن التهجيرات، ليست هي المُتحكمة بالإسكيما الخاصة بقاعدة بياناتك. إن هذا الأمر (التحكم) يعود إلى ملفات db/schema.rb أو ملف SQL. و تلك الملفات تولد من Active Record عن طريق مُعاينة قاعدة البيانات. وإن تلك الملفات ليست مُصممة ليتم التعديل عليها، بل هي تُظهر و تُمثل حالة قاعدة البيانات. ليس هُناك حاجة لعمل جزئية جديدة بتطبيقٍ ما عن طريق إعادة تشغيل جميع التهجيرات بالتطبيق. فإنه من الأسهل و الأسرع إضافة وصف تلك الجزئية للإسكيما الحالية لقاعدة البيانات. هكذا تكون قاعدة البيانات الإختبارية على سبيل المثال، بحيث يتم إهمال الملفات الحالية لقاعدة البيانات (ملف db/schema.rb و db/structre.sql) و يتم تحميلها إلى قاعدة البيانات الإختبارية test database. إن ملفات الإسكيما مُفيدة أيضًا إذا أردت أن تلقي نظرة سريعة إلى الخصائص التي تحملها كائنات Active Record. حيث أن هذه المعلومات لا توجد في كود نموذج قاعدة البيانات و أحيانًا تكون مُنتشرة بين العديد من التهجيرات، لكن المعلومات تكون جميعها موجود في ملفات الإسكيما بشكل مُنظم. 6.2 أنواع إهمال الإسكيما schema dumps هُناك طريقتين أساسيتين لهجر/إهمال إسكيما ما. هذا يكون موجودًا داخل ملف config/application.rb عن طريق إعداد config.active_record.schema_format، و من المُمكن أن يكون ملف روبي ruby: أو sql: إذا كان من نوع روبي ruby: فإنه سيبدو مثل تهجير كبير، و ستجده داخل db/schema.rb، مثال: ActiveRecord::Schema.define(version: 20080906171750) do create_table "authors", force: true do |t| t.string "name" t.datetime "created_at" t.datetime "updated_at" end create_table "products", force: true do |t| t.string "name" t.text "description" t.datetime "created_at" t.datetime "updated_at" t.string "part_number" end end في كثير من الحالات، يتم صُنع هذه الملفات عن طريق مُعاينة قاعدة البيانات و تركيبها باستعمال الدوال المُستخدمة بصُنعها مثل create_table و add-Index و غيرهم. و لأن هذا أمر يكون مُستقل بقاعدة البيانات، فيُمكن استخدامها على أي قاعدة بيانات يدعمها Active Record. ومن فوائد هذا الأمر، أنه يُمكنك توزيع بيانات تطبيق ما على العديد من قواعد البيانات. من سلبيات ملف الإسكيما db/schema.rb أنه لا يُمكنك التعبير عن جميع مُكونات قاعدة البيانات مثل: المُشغلات/مُنشطات triggers و نقاط التحقق check constraints. بينما في التهجير يُمكنك الإستعانة بسطور SQL. و الإسكيما لا يُمكنها أن تحتوي على تلك السطور. لذلك إن إحتوت قاعدتك بيانات على مثل هذه الخصائص، فيجب عليك تحويل صيغة ملف الإسكيما إلى sql:. بدلًا من إهمال استعمال إسكيما Active Record، فإنه يُمكنك إهمال تركيب/تخطيط قاعدة البيانات بإستخدام أدوات مُعينة مثل (أمر rails db:structre:dump ) في ملف db/structre.sql. على سبيل المثال: في قواعد بيانات من نوع PostgreSQL يُمكنك إستخدام pg_dump. أما في قواعد بيانات MySQL و MariaDB فإن الملف سيظهر لك SHOW CREATE TABLE لمُختلف الجداول التي يحويها هذا الملف. 6.3 إهمال الإسكيما و التحكم بالكود المصدري source control لأن أوامر إهمال الإسكيما هي المُنحكم الرئيسي بالإسكيما الخاصة بقاعدة البيانات. لذلك يُنصح بشدة بأن تتأكد من وجودهم بلوحة تحكم المصدر الخاصة بك. إن ملف db/schema.rb يحتوي على النُسخة الحالية من قاعدة البيانات الخاصة بك. هذا يؤكد حدوث الأخطاء عند دمج العديد منها. و حل هذا الأخطاء يكون يدويًا بإبقاء النُسخة الأعلى من المدمجين. 7 Active Record و التكامل المرجعي referential integrity إن Active Record يدعي أن هُناك آلية ذكية في النماذج الخاصة بقواعد البيانات و ليس بقواعد البيانات نفسها. مثل المميزات triggers و constraints التي تضيف هذه الآلية إلى قاعدة البيانات نفسها, و لكنها ليست مُستخدمة بكثرة. التحقيقات مثل validates:foreign_key و uniqueness: true هي التي تُستخدم عن تكامل البيانات بين قواعد البيانات. فأمر dependent: في القواعد المُتصلة يسمح بتدمير الكائن المورَث عند تدمير الكائن المورِث. هذا لا يُمكن ضمان حدوثه في التكامل المرجعي بوجود تحقيقات المفاتيح الأجنبية في قاعدة البيانات. و مع ذلك فإن Active Record لا يوفر جميع الأدوات التي تعمل مُباشرةً مع هذه المميزات، لذلك فإنه يُمكنك إستخدام أمر excute لتنفيذ أوامر SQL. 8 التهجير و البيانات المرجعية seed data حتى لا ننسى أن الهدف الأساسي من خاصية التهجير و هو عمل أوامر تُعدل على الإسكيما بإستخدام أوامر ثابتة و مُتسقة. إن التهجير أيضًا يُمكن إستعماله لإضافة أو تعديل البيانات، و هذا مُفيد في قواعد البيانات الموجودة مُسبقًا التي لا يُمكن تدميرها و إعادة صُنعها. مثل تلك قاعدة البيانات الخاصة بالإنتاج: class AddInitialProducts < ActiveRecord::Migration[5.0] def up 5.times do |i| Product.create(name: "Product ##{i}", description: "A product.") end end def down Product.delete_all end end لإضاافة بيانات أولية seed data بعد صُنع قاعدة البيانات. إن Rails لديها دالة داخلية built-in تُساعد على تسهيل تلك العملية. خصيصًا عند إعادة تحميل قواعد البيانات بشكل مُتكرر أثناء التطوير و الإختبار. يُمكنك إستخدام تلك الخاصية بكتابة أكواد ruby التي تريدها في ملف db/seeds.rb ثُم تشغيل أمر rails db:seed 5.times do |i| Product.create(name: "Product ##{i}", description: "A product.") End و يُمكنك إستخدام تلك الخاصية لإعداد قاعدة بيانات فارغة من البداية. وبذلك نكون قد أنهينا هذه السلسلة المخصصة لتعلّم تهجير Active Record في إطار العمل روبي أون ريلز. المصدر: توثيقات Ruby on Rails.

نحن نعمل في أزمنة مثيرة للاهتمام، ندرك فيها ونتقبّل أنّه عندما ترغب في الحصول على ترقية في شركة ما، يجب أن تصبح مديرًا. لذلك تعني ترقية المنصب أن تُقلل من العمل الذي ستُصبح مسؤولًا عنه. وهذا يعني، بالنسبة لمدير التصميم، قضاء وقتٍ أكثر على البريد الإلكتروني وEvernote، ووقتٍ أقلّ على فوتوشوب وSketch. قد لا يبدو الأمر منطقيًا، ولكن هذا هو ما عليه الحال. لا أقول أننا لسنا بحاجة إلى المدراء، بل نحن في أمسّ الحاجة إلى الأكفاء منهم. لكنّني بدأتُ أفكّر بتسليمنا الأعمى بهذا الركن الأساسي من الشركات الحديثة، وأتحيّر فيما إذا كانت هناك طريقة لإنشاء نظام يقدّر قيمة العمل بقدر الإدارة، مع تحسين مهارات كلتي المجموعتين في نفس الوقت. لقد تحولّتُ إلى منصبي الإداري الأول منذ حوالي 6 سنوات. لا يمكنني أن أتذكر جيدًا الدافع وراءه، لكنّه كان مزيجًا من احتياجات الشركة ورغبتي في تطوير مهنتي (وربما القليل من الحيرة والتساؤل). كما كنتُ وافر الحظ بالعمل مع مدير بارع في إحدى وظائفي الأولى. وهذا كلّه فتح عينيَّ على التحديات والفرص في الإدارة، وجعلني أرغب في المساهمة في ذلك. كان هذا المنصب تجربة تعليمية عظيمة ومتواضعة، وأنا مسرور لخوضها. لكن، قبل بضع سنوات، أصبحت متضايقًا من عملي كمدير. كان في البداية مجرّد صوت داخلي منخفض يسألني: كيف يمكنك أن تصبح مدير تصميم جدير إن لم تعد تصمّم؟ حاولت أن أتجاهله، لكنّ ذلك الصوت بدأ يصبح أعلى بمرور الوقت، وفي نهاية المطاف كان عليّ أن أواجه هذا السؤال بشكل مباشر.المشكلة هي أنّك تملك فرصًا وظيفية أكثر إذا كنت مديرًا. فالمدير يترقّى إلى مدير أقدم، ومن ثم إلى رئيس، رئيس أقدم، وهكذا. أما إذا كنت مصممًا، فمعالم طريقك ستُصبح أقل وضوحًا. بالتأكيد هناك مناصب عليا وقيادية للمصممين، لكنّها نادرًا ما تكافئ التقدم الوظيفي الحقيقي. وهنا تكمن المشكلة. حيث يُجبر بعض المساهمين الأفراد على أن يصبحوا مدراء حتّى لو كانوا يفضّلون تولّي القيادة من قبل شخص آخر، مما يخلق ثقافة إدارية يمكن لها أن تصبح منقطعة الصلة بأنشطة التصميم اليومية إلى حد كبير. لهذا السبب بدأتُ بالتغيّر منذ نهاية العام الماضي؛ لأنني كنتُ متعبًا من ناحية، ولاختبار هذه النظرية من ناحية أخرى. بدأتُ بالابتعاد عن الإدارة، وأصبحتُ مجرّد مصمم من جديد. شعرتُ بالغرابة في البداية. أين ذهبت كل تلك الاجتماعات؟ ما هو ذلك السطح المنبسط الذي كنت أجلس عليه وأعمل في معظم أوقات اليوم؟ ولكن بعد ذلك سَكَنتْ الغرابة، وأصبح الأمر مبهجًا أكثر. أقضي الآن معظم أيامي في تصميم المنتجات، والحديث عن مساعدة الفرق في تنفيذ تلك التصاميم. أدركتُ أنّ مهاراتي في التصميم تراجعت قليلًا، لذا توجّهت إلى مرحلة التعلّم، وقد كان الأمر ممتعًا. ما معنى هذا؟ هل يعني أنني سئمتُ من الإدارة؟ هل كلّ من يختار حياة الإدارة محكوم عليه بالصداع واليأس؟ بالطبع لا! بل العكس، فالعودة إلى كوني مساهمًا فردًا عززّت اعتقادي بأنّ المدراء الأكفاء مهمّون، ونادرون أيضًا. وأتمنى بالتأكيد أن أشغل هذا المنصب مجددًا في المستقبل. لكن ليس الآن. إليك كيف يمكن أن تتماشى الإدارة مع العمل. أعتقد أنّنا بحاجة إلى نظام مهني يشجّع الناس على التأرجح بين دور المساهم الفرد، ودور المدير. ربّما يمكننا توفير "إجازة إدارية" حيث يمكن للمدير أن يصبح مساهمًا فردًا في الفريق لمدة 6 - 9 أشهر. أو ربّما يتسلّم المساهم الفرد دور المدير لمدة من الزمن (أو لمدة مشروع بأكمله) خلال إجازة المدير. لا أعلم على وجه اليقين كيف سيبدو عليه الأمر، لكنّني أعتقد أنّه من المهم أن ندرسه.أن تكون مساهمًا فردًا سيجعلك مديرًا أفضل لأنك تفهم بشكل أفضل ما يمرّ به الفريق يوميًا، كما يضمن تطوير مهاراتك الفنيّة باستمرار. أمّا أن تكون مديرًا فسيجعلك مصممًا أفضل لأنّك تفهم احتياجات قيادة الفِرق بشكل أفضل، مما يتيح لك التواصل بفعّالية أكبر. الإدارة والعمل أحدهما يغذّي الآخر، لذا يجب ألّا نُجبر على اختيار واحد فقط من المسارين. بالطبع هناك بعض التحذيرات، يجب ألا يُكرَه الناس على الإدارة بالادعاء بأنّ الإدارة فقط تساوي التقدّم الوظيفي. فبعض المدراء ليست لديهم الرغبة في أن يصبحوا مساهمين أفراد مجددًا، ولا يجب عليهم ذلك. الأمر كلّه يتمحور حول الاختيار. إذا قمنا بتشجيع (ومكافأة) الناس على حرية استكشاف أنواع مختلفة من الأدوار، فلا شك من أن ذلك سيعود بالنفع على الشركة، والأهم من ذلك، على المستخدمين. ترجمة-وبتصرّف-للمقال Managing and Making: It Doesn’t Have to Be One or the Other لصاحبه: Rian Van Der Merwe حقوق الصورة البارزة محفوظة لـ Freepik