Comment (et si) renseigner l'application Rails avec les données initiales

https://stackoverflow.com/questions/62201

09-06-2019
|

Question

J'ai une application rails dans laquelle les utilisateurs doivent se connecter. Par conséquent, pour que l'application soit utilisable, il doit y avoir un utilisateur initial dans le système avec lequel la première personne à ouvrir une session (ils peuvent ensuite créer utilisateurs). Jusqu'à présent, j'ai utilisé une migration pour ajouter un utilisateur spécial à la base de données.

Après avoir posé cette question , il semble que je devrais utiliser db : schéma: charge, plutôt que d'exécuter les migrations, pour configurer de nouvelles bases de données sur de nouvelles machines de développement. Malheureusement, cela ne semble pas inclure les migrations qui insèrent des données, mais uniquement celles qui configurent des tables, des clés, etc.

Ma question est la suivante: quel est le meilleur moyen de gérer cette situation:

Est-il possible d'obtenir que d: s: l inclue les migrations d'insertion de données?
Ne dois-je pas utiliser les migrations pour insérer des données de cette manière?
Ne devrais-je pas pré-renseigner la base de données avec des données? Dois-je mettre à jour le code de l’application afin qu’il gère le cas où aucun utilisateur ne se trouve normalement et laisse un compte utilisateur initial être créé en direct depuis l’application?
D'autres options? :)

La solution 7

J'ai pensé résumer certaines des bonnes réponses que j'ai eues à cette question, ainsi que mes propres pensées, maintenant je les ai toutes lues:)

Il y a deux problèmes distincts ici:

Dois-je pré-renseigner la base de données avec mon utilisateur "admin" spécial? Ou bien l’application doit-elle fournir un moyen de configuration lors de sa première utilisation?
Comment pré-peupler la base de données avec des données? Notez que cette question est valide quelle que soit la réponse à la partie 1: il existe d’autres scénarios d’utilisation pré-population qu’un utilisateur admin.

Pour (1), il semble que configurer le premier utilisateur à partir de l’application elle-même représente un peu plus de travail supplémentaire, pour une fonctionnalité qui, par définition, n’est pratiquement jamais utilisée. Il peut toutefois être légèrement plus sécurisé, car il oblige l'utilisateur à définir un mot de passe de son choix. La meilleure solution se situe entre ces deux extrêmes: avoir un script (ou une tâche rake, ou autre) pour configurer l'utilisateur initial. Le script peut ensuite être configuré pour être automatiquement renseigné avec un mot de passe par défaut lors du développement et pour exiger la saisie d'un mot de passe lors de l'installation / du déploiement en production (si vous souhaitez décourager un mot de passe par défaut pour l'administrateur).

Pour (2), il semble qu'il existe un certain nombre de solutions valables et valables. Une tâche de rake semble un bon moyen, et il existe des plugins pour rendre cela encore plus facile. Il suffit de parcourir certaines des autres réponses pour voir les détails de celles-ci:)

Autres conseils

Essayez une tâche de rake. Par exemple:

Créez le fichier /lib/tasks/bootstrap.rake
Dans le fichier, ajoutez une tâche pour créer votre utilisateur par défaut:


    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

Ensuite, lorsque vous configurez votre application pour la première fois, vous pouvez faire rake db: migrate OU rake db: schema: load, puis faire rake bootstrap: all.

Utilisez db / seed.rb présent dans toutes les applications Rails.

Bien que certaines des réponses données ci-dessus à partir de 2008 puissent fonctionner correctement, elles sont plutôt obsolètes et ne sont plus vraiment la convention Rails.

Le remplissage des données initiales dans la base de données doit être effectué avec le fichier db / seed.rb .

Cela fonctionne comme un fichier Ruby.

Pour créer et enregistrer un objet, vous pouvez faire quelque chose comme:

User.create (: nom d'utilisateur = > "quotient",: description = > "roi de / b /")

Une fois que vous avez préparé ce fichier, vous pouvez le suivre

rake db: migrer

rake db: seed

Ou en une seule étape

rake db: configuration

Votre base de données doit contenir les objets que vous souhaitez créer dans seed.rb

Je vous recommande de ne pas insérer de nouvelle donnée dans les migrations. Ne modifiez que les données existantes lors des migrations.

Pour insérer les données initiales, je vous recommande d’utiliser YML. Dans chaque projet Rails que j'ai configuré, je crée un répertoire de fixtures sous le répertoire DB. Ensuite, je crée des fichiers YML pour les données initiales, tout comme les fichiers YML sont utilisés pour les données de test. Ensuite, j'ajoute une nouvelle tâche pour charger les données à partir des fichiers YML.

lib / tasks / 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

db / fixtures / users.yml:

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

Ceci est ma nouvelle solution préférée, utilisant les gems populator et faker:

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

Essayez le seed-fu < Le plugin / a>, qui est un simple plugin qui vous permet de créer des données (et de modifier ces données de départ), vous permettra également de générer des données spécifiques à un environnement et des données pour tous les environnements.

Je suppose que la meilleure option est le numéro 3, principalement parce qu’il n’y aura donc aucun utilisateur par défaut, ce qui est un excellent moyen de rendre inutile une sécurité satisfaisante.

Pensez à utiliser la console des rails. Idéal pour les tâches d'administration ponctuelles où il ne vaut pas la peine de mettre en place un script ou une migration.

Sur votre machine de production:

script/console production

... alors ...

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

Si vous générez cet utilisateur initial plusieurs fois, vous pouvez également ajouter un script dans RAILS_ROOT / script / et l'exécuter à partir de la ligne de commande de votre machine de production ou via une tâche capistrano.

Cette tâche Rake peut être fournie par le plugin db-populate:

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

Excellent article de blog à ce sujet: http://railspikes.com/2008/2/1/loading-seed- données

J'utilisais les suggestions de Jay concernant un ensemble spécial de montages, mais je me suis vite retrouvé à créer des données impossibles à utiliser directement avec les modèles (entrées non versionnées lorsque j'utilisais acts_as_versenced)

Je le garderais dans une migration. Bien qu'il soit recommandé d'utiliser le schéma pour les configurations initiales, la raison en est qu'il est plus rapide, évitant ainsi les problèmes. Une seule migration supplémentaire pour les données devrait convenir.

Vous pouvez également ajouter les données dans le fichier de schéma, car leur format est identique à celui des migrations. Vous venez de perdre la fonctionnalité de génération automatique.

Pour les utilisateurs et les groupes, la question des utilisateurs préexistants doit être définie en fonction des besoins de l'application plutôt que des imprévus de la programmation. Peut-être que votre application nécessite un administrateur; puis pré-remplir. Ou peut-être pas - puis ajoutez du code pour demander gracieusement une configuration utilisateur au moment du lancement de l'application.

Sur la question plus générale, il est clair que de nombreuses applications Rails peuvent tirer parti d'une date préremplie. Par exemple, une application de stockage d'adresses aux États-Unis peut également contenir tous les États et leurs abréviations. Pour ces cas, les migrations sont votre ami, je crois.

Certaines des réponses sont obsolètes. Depuis Rails 2.3.4, une fonctionnalité simple appelée Seed est disponible dans db / seed.rb :

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

Il fournit une nouvelle tâche rake que vous pouvez utiliser après vos migrations pour charger des données:

rake db:seed

Seed.rb est un fichier Ruby classique. N'hésitez pas à utiliser toute structure de données classique (tableau, hachages, etc.) et les itérateurs pour ajouter vos données:

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

Si vous souhaitez ajouter des données avec des caractères UTF-8 (très courant en français, espagnol, allemand, etc.), n'oubliez pas d'ajouter au début du fichier:

# ruby encoding: utf-8

Ce Railscast est une bonne introduction: http://railscasts.com/episodes/179-seed -data

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow