Heritage de table

[ernestrenan]

Est ce que ça se fait de directement faire hériter les migrations entre elles comme on fait hériter les modèles.

Code ruby :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|
#un post est au minimum un auteur plus un contenu
      t.text :contenu
      t.integer :user_id #clé étrangère pour identifier l'auteur
 
      t.timestamps
    end
  end
 
  def self.down
    drop_table :posts
  end
end

Puis après on peut faire des articles (et plein d'autres contenus comme des commentaires, des journaux entiers etc.)

Code ruby :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class CreateArticles < CreatePosts
  def self.up
    create_table :posts do |t|
      super(t)
      t.string :titre
      t.string :image
      t.integer :journal_id #clé étrangère pour savoir à quelle édition du journal l'article appartient
    end
  end
 
  def self.down
    drop_table :posts
  end
end

Ou alors il vaut mieux mettre les table en relation avec des clefs comme ça

Code ruby :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|
      t.text :body
      t.integer :user_id #clé étrangère pour identifier l'auteur
 
      t.timestamps
    end
  end
 
  def self.down
    drop_table :posts
  end
end

Code ruby :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class CreateArticles < CreatePosts::Migration
  def self.up
    create_table :posts do |t|
      t.string :titre
      t.string :image
      t.integer :content_id
      t.integer :user_id
      t.integer :journal_id 
    end
  end
 
  def self.down
    drop_table :posts
  end
end

J'ai des arguments contre chacune des deux méthodes : la première implémente une classe abstraite ce qui n'existe pas en rubis donc quand je ferrai ma migration je serai obliger de créer la table ds posts qui restera vide (sauf si je bricole un truc mais c'est pas très rubyesque).
La deuxième sépare le contenu des posts en deux et en regroupe une partie dans la même table ce qui d'un point de vue de la logique objet est assez aberrant.

J'ai vu qu'il y avait une méthode qui consiste à rajouter une colonne type a une table unique mais ça ne correspond pas à ce que je veux faire parce que j'ai au moins 5 types de "Posts" et je vais me retrouver avec plein de colonnes inutiles et les objets pas bien séparés.