Se siembra datos con accesorios peligrosos en Ruby on Rails

Question

Tengo accesorios con datos iniciales que tiene que residir en mi base de datos (países, regiones, vehículos, etc.). Tengo un rastrillo tarea db: semilla que va a sembrar una base de datos

.

namespace :db do
  desc "Load seed fixtures (from db/fixtures) into the current environment's database." 
  task :seed => :environment do
    require 'active_record/fixtures'

    Dir.glob(RAILS_ROOT + '/db/fixtures/yamls/*.yml').each do |file|
      Fixtures.create_fixtures('db/fixtures/yamls', File.basename(file, '.*'))
    end
  end
end

Estoy un poco preocupado porque esta tarea toallitas limpia mi base de datos y carga los datos iniciales. El hecho de que esto es incluso posible hacer más de una vez en la producción me sacó fuera de mí. ¿Esto es normal y no sólo tengo que tener cuidado? ¿O es que la gente suele proteger a una tarea como esta de alguna manera?

Answer 1

Los datos Siembra con accesorios es una muy mala idea.

Cuerpo no se validan y ya que los desarrolladores mayoría de los carriles no utilizan restricciones de base de datos Esto significa que puede obtener fácilmente los datos no válidos o incompletos insertados en su base de datos de producción.

Cuerpo también establecen extrañas identificadores de clave principal de forma predeterminada, lo cual no es necesariamente un problema, pero es molesto para trabajar con ellos.

Hay una gran cantidad de soluciones para esto. Mi favorito personal es una tarea rake que se ejecuta un script Ruby que simplemente utiliza ActiveRecord para insertar registros. Esto es lo que Rails 3 hará con db:seed, pero se puede escribir fácilmente usted mismo.

Complemento esto con un método agrego a ActiveRecord :: Base llamada create_or_update. El uso de este que se puede ejecutar la secuencia de comandos de semillas varias veces, la actualización de los registros antiguos en lugar de lanzar una excepción.

escribí un artículo acerca de estas técnicas hace un tiempo llamado datos de carga de semillas .

Answer 2

En la primera parte de su pregunta, sí que acababa de poner un poco de precaución para ejecutar una tarea de este tipo en la producción. Puse una protección de este tipo en mi tarea arranque / siembra:

task :exit_or_continue_in_production? do
  if Rails.env.production?
    puts "!!!WARNING!!! This task will DESTROY " +
         "your production database and RESET all " +
         "application settings"
    puts "Continue? y/n"
    continue = STDIN.gets.chomp
    unless continue == 'y'
      puts "Exiting..."
      exit! 
    end
  end
end

He creado este GIST por algún contexto.

En la segunda parte de la pregunta - por lo general que realmente quieren dos cosas: a) muy fácilmente la siembra de la base de datos y la configuración de la aplicación para el desarrollo, y b) bootstrapping la aplicación en el servidor de producción (como: la inserción de usuario administrador, la creación de carpetas aplicación depende, etc).

que haría uso de accesorios para la siembra en el desarrollo - todos, desde el equipo entonces ve a los mismos datos en la aplicación y lo que está en aplicación es coherente con lo que está en pruebas. (Por lo general, envuelvo rake app:bootstrap, rake app:seed rake gems:install, etc en rake app:install para que todos puedan trabajar en la aplicación con sólo clonar el repositorio y ejecutar esta una tarea.)

Me sin embargo nunca uso los accesorios para siembra / arranque en el servidor de producción. db/seed.rb rieles es realmente muy bien para esta tarea, pero por supuesto puede poner la misma lógica en su propia tarea rake app:seed, al igual que otros señalaron.

Answer 3

Barras de 3 va a resolver esto para usted usando un archivo seed.rb.

http://github.com/brynary/rails/commit/4932f7b38f72104819022abca0c952ba6f9888cb

Answer 4

Hemos construido un montón de mejores prácticas que utilizamos para los datos de siembra. Nos depender en gran medida de la siembra, y tenemos algunos requisitos únicos ya que necesitamos para sembrar sistemas con varios inquilinos. He aquí algunas de las mejores prácticas que hemos utilizado:

1. accesorios no son la mejor solución, pero todavía se deben almacenar los datos de semillas en algo distinto de Ruby. código Ruby para almacenar datos de semillas tiende a ser repetitivo, y almacenar los datos en un archivo analizable significa que puede escribir código genérico para manejar sus semillas de una manera coherente.
2. Si va a actualizar potencialmente semillas, utilice una columna marcador con un nombre como code para que coincida con su archivo de semillas a los datos reales. Nunca confíe en los identificadores sean consistentes entre los ambientes.
3. Piense acerca de cómo desea gestionar la actualización de datos de semillas existentes. ¿Hay alguna posibilidad de que los usuarios han modificado estos datos? Si es así, debe mantener la información del usuario en lugar de la sustituya por los datos de semillas?

Si está interesado en algunas de las maneras que siembra, les hemos empaquetado en una gema llamada SeedOMatic .

Answer 5

¿Qué hay de simplemente borrar la tarea fuera de su servidor de producción una vez que han sembrado la base de datos?

Answer 6

acabo de tener una idea interesante ...

lo que si ha creado \ semillas \ db \ agregado y archivos de estilo de migración:

archivo: 200907301234_add_us_states.rb

class AddUsStates < ActiveRecord::Seeds

  def up
    add_to(:states, [
      {:name => 'Wisconsin', :abbreviation => 'WI', :flower => 'someflower'},
      {:name => 'Louisiana', :abbreviation => 'LA', :flower => 'cypress tree'}
      ]
    end
  end

  def down
    remove_from(:states).based_on(:name).with_values('Wisconsin', 'Louisiana', ...)
  end
end

alternativamente:

  def up
    State.create!( :name => ... )
  end

Esto permite llevar a cabo migraciones y semillas en un orden que les permita coexistir pacíficamente más.

pensamientos?