public
Description: ActiveRecord Multiple InheriTance. This is an old project and will not see many updates soon.
Homepage: http://swissrb.rubyforge.org
Clone URL: git://github.com/kschiess/armit.git
armit /
name age message
file Changelog Tue Feb 26 11:07:51 -0800 2008 . after save . correcting the manifest git-svn... [kaspar]
file History.txt Mon Mar 31 13:51:11 -0700 2008 + Version comment in History.txt [restorm]
file LICENSE Thu Mar 13 10:20:16 -0700 2008 . making release information more clear - since... [kschiess]
file Manifest.txt Tue Feb 26 11:07:51 -0800 2008 . after save . correcting the manifest git-svn... [kaspar]
file README.txt Thu Mar 13 10:20:16 -0700 2008 . making release information more clear - since... [kschiess]
file Rakefile Wed Jan 02 00:43:36 -0800 2008 - Removed weird test - will have to come up wit... [kaspar]
directory lib/ Wed Feb 27 00:56:09 -0800 2008 ! Fixing test side effect issues git-svn-id: h... [kaspar]
directory spec/ Wed Feb 27 00:56:09 -0800 2008 ! Fixing test side effect issues git-svn-id: h... [kaspar]
directory test/ Sun Dec 30 06:13:46 -0800 2007 + Adding all remaining examples from basic test... [kaspar]
directory wiki/ Wed Oct 10 06:42:27 -0700 2007 ! Fixing a few minor troubles with respond_to? ... [kaspar]
README.txt
= SYNOPSIS

Armit stands for ActiveRecord Multiple Table Inheritance and helps you do just that. Some people also call this Class 
Table Inheritance (http://www.martinfowler.com/eaaCatalog/classTableInheritance.html). 

You should start out with a STI hierarchy of ActiveRecord models. You can then augment each subclass of your hierarchy
with something we call an 'attributes'-table. Together, they form a multi table inheritance layer. This layer permits 
access of multiple tables as if they were one single table. 

= DESCRIPTION

For a conceptual model like this: 

                                                Account
                                                   ^
                                        ___________|____________       
                                        |                       |
                                      Group                   User
                                      
You would create the following database tables: 

  accounts                (this contains all the STI stuff)
  group_attributes        Additional attributes for Group
  user_attributes         Additional attributes for User
  
And connect it like this in your STI layer: 


                                                Account
                                                   ^
                                        ___________|____________       
                                        |                       |
                  GroupAttribute ---- Group                   User ---- UserAttribute

Account, Group and User would be stored in accounts, and then you'd probably create has_one relationships to attributes, 

on each side. 

With armit, you can now use your models the way you draw your conceptual model. Attributes are folded back into the 
dependent classes: 

                                                Account
                                                   ^
                                        ___________|____________       
                                        |                       |
                                      Group                   User

If there is something you could do with the STI-Models, chances are that it will work with the brand new shiny 
MTI-Models
too. We've got everything you need for CRUD and then some. 

= THANKS

Go out to Severin 'can_it_do_this_or_that' Schoepke who put up with ARMIT long before it was feature complete. And to 
the
rest of the pack - thanks for sharing my goals!

= AUTHORS AND LEGALESE

armit was written by Florian Hanke, Kaspar Schiess and Severin Schoepke, restorm.com, 2007. For licensing information 
refer to the file LICENSE.