Rails has_and_belongs_to_many migration

J'ai deux modèles restaurant et user que je veux faire une relation has_and_belongs_to_many.

J'ai déjà allé dans les fichiers de modèle et a ajouté l' has_and_belongs_to_many :restaurants et has_and_belongs_to_many :users

Je suppose, à ce point, je devrais être capable de faire quelque chose comme avec Rails 3:

rails generate migration ....

mais tout ce que j'ai essayé semble échouer. Je suis sûr que c'est quelque chose de vraiment simple, je suis nouveau sur les rails, donc je suis encore en apprentissage.

InformationsquelleAutor dbslone | 2011-07-03

251

Vous avez besoin pour ajouter une table de jointure séparée avec seulement un restaurant_id et user_id (pas de clé primaire), dans ordre alphabétique.

La première exécution de vos migrations, puis éditer le générés fichier de migration.

Rails 3
```
rails g migration create_restaurants_users_table
```
Rails 4:
```
rails g migration create_restaurants_users
```
Rails 5
```
rails g migration CreateJoinTableRestaurantUser restaurants users
```
De la docs:

Il y a aussi un générateur qui va produire les tables de jointure si JoinTable
est une partie du nom:

Votre fichier de migration (note de l' :id => false; c'est ce qui empêche la création d'une clé primaire):

Rails 3
```
class CreateRestaurantsUsers < ActiveRecord::Migration
  def self.up
    create_table :restaurants_users, :id => false do |t|
        t.references :restaurant
        t.references :user
    end
    add_index :restaurants_users, [:restaurant_id, :user_id]
    add_index :restaurants_users, :user_id
  end

  def self.down
    drop_table :restaurants_users
  end
end
```
Rails 4
```
class CreateRestaurantsUsers < ActiveRecord::Migration
  def change
    create_table :restaurants_users, id: false do |t|
      t.belongs_to :restaurant
      t.belongs_to :user
    end
  end
end
```
t.belongs_to va créer automatiquement les indices nécessaires. def change va détecter automatiquement un avant ou la restauration de la migration, pas besoin de up/down.

Rails 5
```
create_join_table :restaurants, :users do |t|
  t.index [:restaurant_id, :user_id]
end
```
Remarque: Il existe également une option pour un nom de table personnalisé qui peut être passé en paramètre à create_join_table appelé table_name. À partir de la docs

Par défaut, le nom de la table de jointure vient de l'union de la
deux premiers arguments fournis à create_join_table, dans l'ordre alphabétique
ordre. Pour personnaliser le nom de la table, de fournir un :table_name
option:
- grâce à cette solution a fonctionné parfaitement pour moi. Fait une simple erreur lors de l'utilisation de cette méthode, j'ai essayé un rake db:migrate après les rails de commande et il n'a pas de générer la table. Eu à faire un rake db:rollback ensuite modifier le fichier puis faire rake db:migrate, mais tout fonctionne maintenant.
- Juste par curiosité, pourriez-vous expliquer pourquoi vous êtes en utilisant un second composé de l'indice, défini à renversé l'ordre des colonnes? J'étais sous l'impression que l'ordre des colonnes n'a pas d'importance. Je ne suis pas DBA, juste envie de poursuivre ma propre compréhension. Merci!
- Vous n'avez pas besoin de cette manière, cela dépend vraiment de vos requêtes. Les indices de lecture de gauche à droite, de sorte que le premier sera plus rapide si vous êtes à la recherche sur restaurant_id. La deuxième va vous aider si vous êtes à la recherche sur user_id. Si vous êtes à la recherche sur les deux, je pense que la base de données serait assez intelligent pour seulement besoin d'une. Donc je suppose que le second n'a pas vraiment besoin d'être aggravée. Ce n'était plus juste un exemple. C'était un Rails de question, cependant, de sorte que l'affichage dans la DB section donnerait une réponse plus complète.
- Le deuxième indice a une certaine redondance - aussi longtemps que vous vous interrogez sur les deux restaurant_id et user_id, leur ordre dans votre SQL n'a pas d'importance, et le premier indice sera utilisé. Il sera également utilisé si vous êtes la seule interrogation sur restaurant_id. Le deuxième indice ne doit être sur :user_id, et seraient utilisés dans le cas où vous êtes la seule interrogation sur user_id (dont le premier indice ne serait pas de l'aide, en raison de l'ordre des clés).
- Merci pour la solution, j'ai voulu dire qu'il y avait une confusion point. Lorsque vous faites référence à la "utilisateur:" les rails de systèmes semble automatiquement référence à la "user_id" sur le terrain. J'ai été un peu accroché sur que pour un peu.
- Oui, il y a beaucoup de construit dans les trucs qui s'appuie sur des conventions de nommage dans les Rails
- Dans les rails 4 la migration doit être rails g migration create_restaurants_users sans table à la fin.
- Vous pouvez également utiliser des rails g de migration CreateJoinTableRestaurantUser restaurant de l'utilisateur. Lire guides.rubyonrails.org/migrations.html#creating-a-join-table
- Vous souhaitez également supprimer l'index dans l'auto.down call probablement
- Quel est le but de l'indexation de l'user_id seul? Pourquoi n'est-ce pas fait pour tout le restaurant_id ainsi?
- Le premier indice (sur deux colonnes), la plupart du temps doit être unique.
- Intéressant de noter que create_join_table peut être utilisé au moins dans les Rails >= 4.2
InformationsquelleAutor Dex
32

Les réponses ici sont assez daté. Comme des Rails 4.0.2, votre migrations de faire usage de create_join_table.

Pour créer la migration, exécutez:
```
rails g migration CreateJoinTableRestaurantsUsers restaurant user
```
Cela va générer le suivant:
```
class CreateJoinTableRestaurantsUsers < ActiveRecord::Migration
  def change
    create_join_table :restaurants, :users do |t|
      # t.index [:restaurant_id, :user_id]
      # t.index [:user_id, :restaurant_id]
    end
  end
end
```
Si vous voulez indexer ces colonnes, décommentez les lignes concernées et vous êtes bon pour aller!
- J'ai, de manière générale, supprimez le commentaire d'une de l'indice des lignes et ajouter unique: true à elle. Cela permettra d'éviter de dupliquer la création de relations.
InformationsquelleAutor Jan Klimo
26

Lors de la création de la table de jointure, en faisant attention à la condition que les deux tables doivent être répertoriés dans ordre alphabétique dans le nom de la migration/classe. Cela peut facilement vous mordre si votre modèle de noms sont similaires, par exemple, "abc" et "abb". Si vous deviez exécuter
```
rails g migration create_abc_abb_table
```
Vos relations pas fonctionner comme prévu. Vous devez utiliser
```
rails g migration create_abb_abc_table
```
à la place.
- Qui vient en premier? foo ou foo_bar?
- Couru dans une console rails: ["foo_bar", "foo", "foo bar"].trier # => ["foo", "foo bar", "foo_bar"] Unix trier vient la même.
InformationsquelleAutor shacker
6

Pour les relations HABTM, vous devez créer une table de jointure. Il y est seulement de rejoindre la table et que le tableau ne devrait pas avoir une colonne d'id. Essayez cette migration.
```
def self.up
  create_table :restaurants_users, :id => false do |t|
    t.integer :restaurant_id
    t.integer :user_id
  end
end

def self.down
  drop_table :restaurants_users
end
```
Vous devez vérifier cette relation rails de guide tutoriels
- Je ne pense pas que vous avez besoin d'un modèle et je ne vois rien dans le lien sur le besoin d'un modèle pour une relation HABTM.
- Pour accélérer les requêtes générées, ajouter les indices de l'id des champs.
InformationsquelleAutor Mohit Jain

Vous devez vous connecter pour publier un commentaire.