كيف (وما إذا كان) سيتم ملء تطبيق Rails بالبيانات الأولية

Question

لدي تطبيق Rails حيث يجب على المستخدمين تسجيل الدخول.لذلك، لكي يكون التطبيق قابلاً للاستخدام، يجب أن يكون هناك مستخدم أولي واحد في النظام ليتمكن الشخص الأول من تسجيل الدخول باستخدامه (يمكنه بعد ذلك إنشاء مستخدمين لاحقين).لقد استخدمت حتى الآن عملية ترحيل لإضافة مستخدم خاص إلى قاعدة البيانات.

بعد السؤال هذا السؤال, ، يبدو أنني يجب أن أستخدم db:schema:load، بدلاً من تشغيل عمليات الترحيل، لإعداد قواعد بيانات جديدة على أجهزة التطوير الجديدة.لسوء الحظ، لا يبدو أن هذا يشمل عمليات الترحيل التي تُدرج البيانات، فقط تلك التي تقوم بإعداد الجداول والمفاتيح وما إلى ذلك.

سؤالي هو: ما هي أفضل طريقة للتعامل مع هذا الموقف:

1. هل هناك طريقة للحصول على d:s:l لتضمين عمليات ترحيل إدراج البيانات؟
2. هل يجب ألا أستخدم عمليات الترحيل على الإطلاق لإدراج البيانات بهذه الطريقة؟
3. هل يجب ألا أقوم بملء قاعدة البيانات مسبقًا بالبيانات على الإطلاق؟هل يجب عليّ تحديث رمز التطبيق بحيث يتعامل مع الحالة التي لا يوجد فيها مستخدمون بأمان، ويسمح بإنشاء حساب مستخدم أولي مباشرة من داخل التطبيق؟
4. هل هناك أي خيارات أخرى؟:)

Answer 1

اعتقدت أنني سألخص بعض الإجابات الرائعة التي تلقيتها على هذا السؤال، بالإضافة إلى أفكاري الخاصة الآن بعد أن قرأتها جميعًا :)

هناك مسألتان متميزتان هنا:

1. هل يجب عليّ ملء قاعدة البيانات مسبقًا بالمستخدم "المسؤول" الخاص بي؟أم يجب أن يوفر التطبيق طريقة للإعداد عند استخدامه لأول مرة؟
2. كيف يمكن للمرء ملء قاعدة البيانات بالبيانات مسبقًا؟لاحظ أن هذا سؤال صالح بغض النظر عن إجابة الجزء الأول:هناك سيناريوهات استخدام أخرى للتجميع المسبق بخلاف المستخدم الإداري.

بالنسبة إلى (1)، يبدو أن إعداد المستخدم الأول من داخل التطبيق نفسه يتطلب قدرًا كبيرًا من العمل الإضافي، بالنسبة للوظيفة التي، بحكم التعريف، نادرًا ما يتم استخدامها على الإطلاق.ومع ذلك، قد يكون أكثر أمانًا قليلاً، لأنه يجبر المستخدم على تعيين كلمة مرور من اختياره.الحل الأفضل هو بين هذين النقيضين:لديك برنامج نصي (أو مهمة أشعل النار، أو أي شيء آخر) لإعداد المستخدم الأولي.يمكن بعد ذلك إعداد البرنامج النصي بحيث يتم ملؤه تلقائيًا بكلمة مرور افتراضية أثناء التطوير، ويطلب إدخال كلمة مرور أثناء تثبيت/نشر الإنتاج (إذا كنت تريد عدم استخدام كلمة مرور افتراضية للمسؤول).

وفي (2) يبدو أن هناك عددًا من الحلول الجيدة والصالحة.تبدو مهمة أشعل النار طريقة جيدة، وهناك بعض المكونات الإضافية لتسهيل ذلك.ما عليك سوى إلقاء نظرة على بعض الإجابات الأخرى لمعرفة تفاصيلها :)

Answer 2

جرب مهمة أشعل النار.على سبيل المثال:

1. قم بإنشاء الملف /lib/tasks/bootstrap.rake
2. في الملف، أضف مهمة لإنشاء المستخدم الافتراضي الخاص بك:

    namespace :bootstrap do
      desc "Add the default user"
      task :default_user => :environment do
        User.create( :name => 'default', :password => 'password' )
      end

      desc "Create the default comment"
      task :default_comment => :environment do
        Comment.create( :title => 'Title', :body => 'First post!' )
      end

      desc "Run all bootstrapping tasks"
      task :all => [:default_user, :default_comment]
    end

3. وبعد ذلك، عندما تقوم بإعداد تطبيقك لأول مرة، يمكنك القيام بـ rake db:migrate أو rake db:schema:load، ثم القيام بـ rake bootstrap:all.

Answer 3

يستخدم db/seed.rb موجود في كل تطبيق Rails.

في حين أن بعض الإجابات الواردة أعلاه من 2008 يمكن أن تعمل بشكل جيد، فهي قديمة جدًا ولم تعد تمثل اتفاقية Rails بعد الآن.

ينبغي أن يتم نشر البيانات الأولية في قاعدة البيانات db/seed.rb ملف.

إنه يعمل مثل ملف روبي.

لإنشاء كائن وحفظه، يمكنك القيام بشيء مثل:

User.create(:username => "moot", :description => "king of /b/")

بمجرد أن يكون هذا الملف جاهزًا، يمكنك القيام بما يلي

rake db:migrate

rake db:seed

أو في خطوة واحدة

rake db:setup

يجب أن يتم ملء قاعدة البيانات الخاصة بك بالكائنات التي تريد إنشاءها في Seed.rb

Answer 4

أنصحك بعدم إدراج أي جديد البيانات في الهجرات.بدلاً من ذلك، قم فقط بتعديل البيانات الموجودة في عمليات الترحيل.

لإدراج البيانات الأولية، أنصحك باستخدام YML.في كل مشروع ريلز أقوم بإعداده، أقوم بإنشاء دليل Fixtures ضمن دليل DB.ثم أقوم بإنشاء ملفات YML للبيانات الأولية تمامًا مثلما يتم استخدام ملفات YML لبيانات الاختبار.ثم أقوم بإضافة مهمة جديدة لتحميل البيانات من ملفات YML.

ليب/المهام/db.rake:

namespace :db do
  desc "This loads the development data."
  task :seed => :environment do
    require 'active_record/fixtures'
    Dir.glob(RAILS_ROOT + '/db/fixtures/*.yml').each do |file|
      base_name = File.basename(file, '.*')
      say "Loading #{base_name}..."
      Fixtures.create_fixtures('db/fixtures', base_name)
    end
  end

  desc "This drops the db, builds the db, and seeds the data."
  task :reseed => [:environment, 'db:reset', 'db:seed']
end

ديسيبل/تركيبات/users.yml:

test:
  customer_id: 1
  name: "Test Guy"
  email: "test@example.com"
  hashed_password: "656fc0b1c1d1681840816c68e1640f640c6ded12"
  salt: "188227600.754087929365988"

Answer 5

هذا هو الحل الجديد المفضل لدي، باستخدام أداة الحشد والجواهر المزيفة:

http://railscasts.com/episodes/126-population-a-database

Answer 6

جرب ال البذور فو البرنامج المساعد، وهو مكون إضافي بسيط للغاية يسمح لك ببذر البيانات (وتغيير تلك البيانات البذرية في المستقبل)، سيسمح لك أيضًا ببذر البيانات والبيانات الخاصة بالبيئة لجميع البيئات.

Answer 7

أعتقد أن الخيار الأفضل هو الخيار رقم 3، لأنه بهذه الطريقة لن يكون هناك مستخدم افتراضي، وهي طريقة رائعة لجعل الأمان الجيد عديم الفائدة.

Answer 8

فكر في استخدام وحدة التحكم Rails.مناسب للمهام الإدارية لمرة واحدة حيث لا يستحق الأمر بذل الجهد لإعداد برنامج نصي أو الترحيل.

على آلة الإنتاج الخاصة بك:

script/console production

...ثم ...

User.create(:name => "Whoever", :password => "whichever")

إذا كنت تقوم بإنشاء هذا المستخدم الأولي أكثر من مرة، فيمكنك أيضًا إضافة برنامج نصي في RAILS_ROOT/script/، وتشغيله من سطر الأوامر على جهاز الإنتاج الخاص بك، أو عبر مهمة capistrano.

Answer 9

يمكن توفير مهمة Rake هذه بواسطة المكون الإضافي db-populate:

http://github.com/joshknowles/db-populate/tree/master

Answer 10

مشاركة مدونة رائعة حول هذا:http://railspikes.com/2008/2/1/loading-seed-data

كنت أستخدم اقتراحات جاي لمجموعة خاصة من التركيبات، ولكن سرعان ما وجدت نفسي أقوم بإنشاء بيانات لن يكون من الممكن استخدامها باستخدام النماذج مباشرةً (الإدخالات التي لم يتم إصدارها عندما كنت أستخدم act_as_versioned)

Answer 11

سأحتفظ بها في الهجرة.في حين أنه من المستحسن استخدام المخطط للإعدادات الأولية، فإن السبب في ذلك هو أنه أسرع، وبالتالي تجنب المشاكل.يجب أن يكون الترحيل الإضافي الوحيد للبيانات أمرًا جيدًا.

يمكنك أيضًا إضافة البيانات إلى ملف المخطط، حيث إنه بنفس تنسيق عمليات الترحيل.ستفقد ميزة الإنشاء التلقائي.

Answer 12

بالنسبة للمستخدمين والمجموعات، يجب تحديد مسألة المستخدمين الموجودين مسبقًا فيما يتعلق باحتياجات التطبيق بدلاً من طوارئ البرمجة.ربما يتطلب تطبيقك مسؤولاً؛ثم قم بالتعبئة المسبقة.أو ربما لا - ثم أضف رمزًا لطلب إعداد المستخدم بأمان في وقت تشغيل التطبيق.

فيما يتعلق بالسؤال الأكثر عمومية، من الواضح أن العديد من تطبيقات Rails يمكنها الاستفادة من التاريخ المعبأ مسبقًا.على سبيل المثال، قد يحتوي طلب الاحتفاظ بالعنوان في الولايات المتحدة أيضًا على جميع الولايات ومختصراتها.في هذه الحالات، أعتقد أن الهجرات هي صديقتك.

Answer 13

بعض الإجابات قديمة.منذ الإصدار 2.3.4 من Rails، هناك ميزة بسيطة تسمى Seed متوفرة في db/seed.rb :

#db/seed.rb
User.create( :name => 'default', :password => 'password' )
Comment.create( :title => 'Title', :body => 'First post!' )

يوفر مهمة Rake جديدة يمكنك استخدامها بعد عمليات الترحيل لتحميل البيانات:

rake db:seed

Seed.rb هو ملف Ruby كلاسيكي، فلا تتردد في استخدام أي بنية بيانات كلاسيكية (مصفوفة، تجزئة، وما إلى ذلك) ومكررات لإضافة بياناتك:

["bryan", "bill", "tom"].each do |name|
  User.create(:name => name, :password => "password")
end

إذا كنت تريد إضافة بيانات بأحرف UTF-8 (شائعة جدًا في اللغات الفرنسية والإسبانية والألمانية وما إلى ذلك)، فلا تنس أن تضيف في بداية الملف:

# ruby encoding: utf-8

يعد Railscast مقدمة جيدة: http://railscasts.com/episodes/179-seed-data