No release in over 3 years
Low commit activity in last 3 years
Class table inheritance for ActiveRecord based on updatable views in the database that join parent and children tables
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
 Dependencies

Development

~> 1.3
~> 4.2.8
>= 0

Runtime

~> 4.2.8
>= 0
 Project Readme

Class Table Inheritance¶ ↑

Class Table Inheritance for ActiveRecord using updateable views.

More about the pattern on www.martinfowler.com/eaaCatalog/classTableInheritance.html. This gem messes very little with Rails inheritance mechanism. Instead it relies on updatable views in the database to represent classes in the inheritance chain. The approach was first suggested by John Wilger.

Requirements¶ ↑

Rails: 4.x

Ruby: 1.9.3+

Database: PostgreSQL 8.1+ only. Patches for other DBMS are welcome. Note that you are not required to use updateable views, children relations can be tables (with some triggers involved) or materialized views.

Install¶ ↑

Run

gem install updateable_views_inheritance

Usage¶ ↑

Setup¶ ↑

  • In Gemfile add gem 'updateable_views_inheritance'

  • Run rails generate updateable_views_inheritance:install && rake db:migrate

  • In config/environment.rb set config.active_record.schema_format = :sql

  • In case you're using fixtures, don't forget to run

    rake updateable_views_inheritance:fixture
    

after every change to the class hierarchy. Otherwise tests may fail.

Example¶ ↑

class CtiExample < ActiveRecord::Migration
  def self.up
    create_table :locomotives do |t|
      t.column :name, :string
      t.column :max_speed, :integer
      t.column :type, :string
    end

    create_child(:steam_locomotives, :parent => :locomotives) do |t|
      t.decimal :water_consumption, :precision => 6, :scale => 2
      t.decimal :coal_consumption,  :precision => 6, :scale => 2
    end

    create_child(:electric_locomotives, :table => :raw_electric_locomotives, :parent => :locomotives)  do |t|
      t.decimal :electricity_consumption, :precision => 6, :scale => 2
    end
  end

  def self.down
    drop_child  :steam_locomotives
    drop_child  :electric_locomotives
    drop_table  :locomotives
  end
end

And the models:

class Locomotive
end

class SteamLocomotive < Locomotive
  self.table_name =  :steam_locomotives
end

class ElectricLocomotive < Locomotive
  self.table_name =  :electric_locomotives
end

Note that models of children classes must specify table name explicitly.

Changing Columns in Underlying Tables¶ ↑

class RemoveColumnInParentTable < ActiveRecord::Migration
  def self.up
    remove_parent_and_children_views(:locomotives)
    remove_column(:locomotives, :max_speed)
    rename_column(:name, :title)
    rebuild_parent_and_children_views(:locomotives)
  end
end

Renaming Underlying Tables¶ ↑

remove_parent_and_children_views(:old_name)
rename_table(:old_name,:new_name)
execute "UPDATE updateable_views_inheritance SET child_aggregate_view = 'new_name' WHERE child_aggregate_view = 'old_name'"
execute "UPDATE updateable_views_inheritance SET parent_relation = 'new_name' WHERE parent_relation = 'old_name'"
rebuild_parent_and_children_views(:new_name)

Removing Classes¶ ↑

Note that you should remove only leaf classes (i.e. those that do not have descendants). If you want to erase a whole chain or part of chain you have to remove first the leaves and then their ancestors. Use drop_child(child_view) in migrations.

Compatibility with Single Table Inheritance¶ ↑

The approach of this gem is completely independent from Rails built-in Single Table Inheritance. STI and CLTI can safely be mixed in one inheritance chain.

Testing Your App¶ ↑

If you use fixtures, you must run rake updateable_views_inheritance:fixture to generate fixture for the updateable_views_inheritance table after you add/remove classes from the hierarchy or change underlying table or view names. Without it primary key sequence for inheritors' tables won't be bumped to the max and it might not be possible to save objects! If you don't use fixtures for the classes in the hierarchy you don't need to do that.

This gem re-enables referential integrity on fixture loading. This means that

fixtures :all

may fail when there are foreign key constraints on tables. To fix this, explicitly declare fixture load order in test_helper.rb:

fixtures :roots, :trunks, :leafs, ...

for all fixtures you want to load.

Gem Development & Testing¶ ↑

The gem has a comprehensive test suite. In order to run it, your user must be a superuser in PostgreSQL. If this is not the case, run createuser -s pesho (assuming your Unix account is pesho).