# Generic SingleTable inheritance

**URL:** <https://www.ruby-forum.com/t/generic-singletable-inheritance/96839>\
**Category:** Rails\
**Created:** [July 2, 2006, 11:55am UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839 "2006-07-02T11:55:13Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 2, 2006, 11:55am UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/1 "2006-07-02T11:55:13Z")

</div>

Hi all,  
I would like to discuss a design idea I have in mind with you, in order  
to get critical feedback.

ActiveRecord supports single table inheritance(STI) “per se”, BUT you  
must add all possible instance variables(properties) of all subclasses  
to the “base table”(as columns). I would like to circumvent this  
restriction.

Say we have a  
class AbstractGenericThing \< ActiveRecord:Base  
has\_many :properties  
end  
In order to support STI the abstract\_generic\_things-table must have a  
:type column.  
Next comes the Property class  
class Property \< ActiveRecord:Base  
belongs\_to :GenericObject  
end  
The properties table has the following columns  
:key, :string  
:value, :string  
-\> hence we have a simple key-value-pair table.

Now any class which subclasses AbstractGenericThing inherits the  
properties-array. A subclass can have as many properties as it requires.  
So far we can have concrete (sub)classes for our concrete domain objects  
but the property handling is not yet “intuitive”.  
Enter ‘method\_missing’-hook

class AbstractGenericThing

# all methods which are not defined are handled as

# properties

def method\_missing(methodname, \*args)  
methodnameStr = methodname.to\_s  
if (methodnameStr.include? “=”)  
# it’s a setter!  
# remove the trailing =  
methodnameStr.chop!  
return setProperty(methodnameStr, args[0])  
else  
# it’s a getter!  
return getProperty(methodnameStr)  
end  
end

# helper method for setting the given property

def setProperty(propertyName, value)  
property = self.properties.find(:first, :conditions =\> [ “name = ?”,  
propertyName])  
if (property.nil?)  
# Looks like the property does not yet exist.  
# Create it and set the value…  
property = Property.new(:name =\> propertyName, :value =\> value)  
# add this new property to my properties  
self.properties \<\< property  
# safe?  
else  
# change the property’s value  
p “modifying property”  
property.value = value  
property.save  
#self.safe  
end  
end

# helper method for getting the value of the given property

def getProperty(propertyName)  
# there should be(at most) one  
property = properties.find(:first, :conditions =\> [ “name = ?”,  
propertyName])  
if (property.nil?)  
return nil  
else  
return property.value  
end  
end  
end

Now we can dynamically “add” properties to our conrete objects(classes).  
E.g.:

class Person \< AbstractGenericThing  
end

person = Person.new  
person.GivenName = “John”  
person.Name = “Smith”  
person.GivenName

> > John  
> > person.Name
> 
> > Smith  
> > …

Persistence works as expected, hence I am inclined to go with this  
design.  
BEFORE I do I would like to hear what you think? What am I missing(apart  
from the semantics I loose as all properties are stored as strings)?

Thanks for any critical input!  
Clemens

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 2, 2006, 7:10pm UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/2 "2006-07-02T19:10:00Z")

</div>

On Sun, Jul 02, 2006 at 11:55:13AM +0200, Clemens W. wrote:  
} Hi all,  
} I would like to discuss a design idea I have in mind with you, in  
order  
} to get critical feedback.  
}  
} ActiveRecord supports single table inheritance(STI) “per se”, BUT you  
} must add all possible instance variables(properties) of all subclasses  
} to the “base table”(as columns). I would like to circumvent this  
} restriction.  
[…]  
} Persistence works as expected, hence I am inclined to go with this  
} design.  
} BEFORE I do I would like to hear what you think? What am I  
missing(apart  
} from the semantics I loose as all properties are stored as strings)?

Please take a look at  
[http://redcorundum.blogspot.com/2006/07/ror-additional-attributes-with-sti.html](http://redcorundum.blogspot.com/2006/07/ror-additional-attributes-with-sti.html)

I’d been meaning to post about it for a while, and you got me to  
actually  
write it up.

} Thanks for any critical input!  
} Clemens  
–Greg

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 2, 2006, 9:21pm UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/3 "2006-07-02T21:21:42Z")

</div>

Gregory S. wrote:

> On Sun, Jul 02, 2006 at 11:55:13AM +0200, Clemens W. wrote:  
> } Hi all,  
> } I would like to discuss a design idea I have in mind with you, in  
> order  
> } to get critical feedback.  
> }  
> } ActiveRecord supports single table inheritance(STI) “per se”, BUT you  
> } must add all possible instance variables(properties) of all subclasses  
> } to the “base table”(as columns). I would like to circumvent this  
> } restriction.  
> […]  
> } Persistence works as expected, hence I am inclined to go with this  
> } design.  
> } BEFORE I do I would like to hear what you think? What am I  
> missing(apart  
> } from the semantics I loose as all properties are stored as strings)?
> 
> Please take a look at  
> [http://redcorundum.blogspot.com/2006/07/ror-additional-attributes-with-sti.html](http://redcorundum.blogspot.com/2006/07/ror-additional-attributes-with-sti.html)
> 
> I’d been meaning to post about it for a while, and you got me to  
> actually  
> write it up.
> 
> } Thanks for any critical input!  
> } Clemens  
> –Greg

Dear Greg,  
thanks for posting your thoughts about this issue. Your solution brings  
in mainly two improvements over mine.

1. Replacing ‘method\_missing’ by meta prgramming(‘additional\_attribute’)  
This is definitely an improvement. Not only in performance(which might  
not be an issue) but mainly due to explicitness. Though this approach is  
applicable for the non-serialize-solution too. Or am I wrong?

2. Persisting properties/attributes with ActiveRecord’s serialize(yaml)  
If you are absolutely sure that the properties are not needed for any  
(Db-)lookup I agree that the serialze-approach is way better(performance  
and simplicity). In my case I might need a lookup some properties so I  
am not sure whether I should switch to serialize.

Regards  
Clemens

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 2, 2006, 11:30pm UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/4 "2006-07-02T23:30:48Z")

</div>

Ashley M. wrote:

> On Jul 02, 2006, at 10:55 am, Clemens W. wrote:
> 
> > I would like to discuss a design idea I have in mind with you, in  
> > order  
> > to get critical feedback.
> > 
> > ActiveRecord supports single table inheritance(STI) “per se”, BUT you  
> > must add all possible instance variables(properties) of all subclasses  
> > to the “base table”(as columns). I would like to circumvent this  
> > restriction.
> 
> Hi Clemens
> 
> I was going to reply to you earlier - I won’t offer any feed back  
> because it seems Greg has given you everything you need. What I’m  
> curious about, though, is why you brought this up in the context of  
> STI?

I first had my Db schema which had the properties table. Then I thought  
it would be nice if I could still have concrete classes for my various  
domain objects. I then came across STI in the AWDwR-book but didn’t want  
to give up the “flexibility” in the Db schema. This lead me to my  
proposal.

> Right now I’m very interested in solving both the missing  
> information and inheritance problems. Your problem seems separate  
> from inheritance though,

As mentioned above I still want to have specific(concrete) classes for  
my domain objects, but I do not yet know all properties these classes  
will have AND I don’t want to change the Db-schema everytime a new  
domain object(and/or) property for domain object comes up. Maybe I am  
looking too much into the future(not really XP’ish, I know).

> because your solution allows a class to have  
> any properties.  
> What was it that made you need these arbitrary  
> properties anyway?

see my answers above. Also note in my last post that I admit that Greg’s  
declarative(meta-programming) approach is “better”. Greg’s approach is  
less “arbitrary”, which is fine for my project, too.

> Actually I’ve thought of one useful thing I can pass on. Our  
> company’s wiki runs on XWiki, and this has a very basic schema. What  
> they do is use one table per database type - I believe they are named  
> something like ‘xwikistrings’, ‘xwikiintegers’, ‘xwikibooleans’,  
> etc. This way you get the flexibility without losing the ability to  
> do things “SELECT values FROM properties WHERE value \> 3” efficiently.
> 
> Ashley

At the moment I do not see any need for absolutely needing to know the  
type of my properties.

I am really happy getting this kind of critical feedback. It makes me  
rethink and maybe even reject my decision, which is ok in the beginning  
of a project 😉

Regards  
Clemens

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 2, 2006, 10:00pm UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/5 "2006-07-02T22:00:24Z")

</div>

On Jul 02, 2006, at 10:55 am, Clemens W. wrote:

> I would like to discuss a design idea I have in mind with you, in  
> order  
> to get critical feedback.
> 
> ActiveRecord supports single table inheritance(STI) “per se”, BUT you  
> must add all possible instance variables(properties) of all subclasses  
> to the “base table”(as columns). I would like to circumvent this  
> restriction.

Hi Clemens

I was going to reply to you earlier - I won’t offer any feed back  
because it seems Greg has given you everything you need. What I’m  
curious about, though, is why you brought this up in the context of  
STI? Right now I’m very interested in solving both the missing  
information and inheritance problems. Your problem seems separate  
from inheritance though, because your solution allows a class to have  
any properties. What was it that made you need these arbitrary  
properties anyway?

Actually I’ve thought of one useful thing I can pass on. Our  
company’s wiki runs on XWiki, and this has a very basic schema. What  
they do is use one table per database type - I believe they are named  
something like ‘xwikistrings’, ‘xwikiintegers’, ‘xwikibooleans’,  
etc. This way you get the flexibility without losing the ability to  
do things “SELECT values FROM properties WHERE value \> 3” efficiently.

Ashley

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 2, 2006, 11:43pm UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/6 "2006-07-02T23:43:48Z")

</div>

> As mentioned above I still want to have specific(concrete) classes for  
> my domain objects, but I do not yet know all properties these classes  
> will have

uhhuh…another ActiveRDF candidate. theres really a lot of reading out  
there on the subject, but for starters, id try the ActiveRDF docs[3],  
the pdf from Obie F. ‘Deep Integration of Ruby with Semantic Web  
Ontologies’[2], and a page from the W3C (concepts and abstract  
syntax)[1].

1. [Resource Description Framework (RDF): Concepts and Abstract Syntax](http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/)
2. [http://gigaton.thoughtworks.net/~ofernand1/DeepIntegration.pdf](http://gigaton.thoughtworks.net/~ofernand1/DeepIntegration.pdf)
3. [http://activerdf.org/manual/manual.html](http://activerdf.org/manual/manual.html)

> I am really happy getting this kind of critical feedback. It makes me  
> rethink and maybe even reject my decision

no!! go with your instincts. just figure out a way to make them happen…  
c

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 3, 2006, 12:21am UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/7 "2006-07-03T00:21:35Z")

</div>

Hi!

On Jul 2, 2006, at 12:21 PM, Clemens W. wrote:

> > subclasses  
> > Please take a look at
> 
> applicable for the non-serialize-solution too. Or am I wrong?  
> Clemens  
> Clemens-

```
If you use ferret and acts_as_ferret for your db searches then you

```

can define a custom .to\_doc method in your models that hints to  
ferret how to index and search your serialized attributes. This lets  
you use nice serialization for meta data and stuff that changes too  
often to go in the db. And you still get full text and fuzzy text  
search on these serialized attributes.

Cheers-  
-Ezra

---

<div class="post-metadata">

**Author:** ![clemens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/df788c/32.png) [@clemens](https://www.ruby-forum.com/u/clemens)\
**Post date:** [July 3, 2006, 12:27am UTC](https://www.ruby-forum.com/t/generic-singletable-inheritance/96839/8 "2006-07-03T00:27:50Z")

</div>

On Jul 02, 2006, at 10:30 pm, Clemens W. wrote:

> I first had my Db schema which had the properties table. Then I  
> thought  
> it would be nice if I could still have concrete classes for my various  
> domain objects. I then came across STI in the AWDwR-book but didn’t  
> want  
> to give up the “flexibility” in the Db schema. This lead me to my  
> proposal.

Clemens

Is this an existing schema you’ve inherited, or just your first draft  
at a new project?

> As mentioned above I still want to have specific(concrete) classes for  
> my domain objects, but I do not yet know all properties these classes  
> will have AND I don’t want to change the Db-schema everytime a new  
> domain object(and/or) property for domain object comes up. Maybe I am  
> looking too much into the future(not really XP’ish, I know).

Obviously without going into the requirements of your project I can’t  
say what would suit you best. But I approach database design as a  
mapping of business (or personal) requirements to facts. So if I  
have a business need (say a legal requirement) to store a date of  
birth of (say) an employee, then in it goes, as a specific column.  
Properties as rows rather than columns strike me as more useful for  
lookups rather than general queries. IE it’s easy to get all the  
properties of a given employee, but hard to write queries like “Find  
all managers more than 10 years older than the youngest employee they  
supervise” (or something less contrived). Because data tends to  
outlive applications, I prefer to go with the design that facilitates  
ad-hoc queries.

As for XP, have you tried continuous integration? I’ve never done it  
with Ruby/Rails but I believe there’s a tool called DamageControl.  
CI lets you change the database as much as you like and still have  
absolute confidence it will work when you deploy live. Used with  
Migrations it should give you XP flexibility with old-fashioned  
stability. (I believe that database CI is as important as unit  
testing.)

> see my answers above. Also note in my last post that I admit that  
> Greg’s  
> declarative(meta-programming) approach is “better”. Greg’s approach is  
> less “arbitrary”, which is fine for my project, too.

I like that solution from the Ruby side, but not the database side.  
If I was going to use this property-based idea, I’d marry the two,  
and take your separate property table but use the explicit  
“additional\_attribute :foo, :bar” metaprogramming to create the Ruby  
attributes.

Just for comparison, here’s a similar solution to a problem that  
cropped up at work. I’ve only just convinced my boss to start using  
Rails, and he set one of our developers on to this small project for  
calculating online IT quotations. Basically, we want the available  
components for a quote (eg photocopiers, phones, faxes, whatever they  
want to sell) to be determined from the database, and have the GUI  
driven by the records it finds. But we don’t want to have to  
duplicate all that information in the model class either. So what I  
suggested is to make a Calculation class that subclasses OpenStruct,  
and add an “identifier” column into the component records that will  
be the Ruby attribute name. The neat thing about that is that you  
can use Rails’ block HTML form assignment to construct a whole model  
class. Then the code looks something like this:

class Calc \< OpenStruct  
def calc  
total = 0  
if self.respond\_to?(:num\_photocopiers)  
total += \* self.num\_photocopiers  
end  
total  
end  
end

In fact, simple cases like that could be done even more elegantly by  
adding a boolean “simple” attribute to the database, that indicated  
to the code it could do a simple PRICE \* QTY calc - it’s only the  
case where one item implicitly requires ordering one or more other  
parts that you need to write extra calculation rules.

While it’s not completely database driven, it’s got us 50% of the way  
there with VERY little coding at all. (I’m not sure the developer  
gets how it works yet, but soon he will have an AHA! moment and join  
the metaprogramming crowd!)

This of course is a different problem to yours but I thought I’d  
share it for comparison.

> At the moment I do not see any need for absolutely needing to know the  
> type of my properties.

What better reason for making sure you record them ;o) (See above  
for my obsession with making ad-hoc queries as easy as possible).

> I am really happy getting this kind of critical feedback. It makes me  
> rethink and maybe even reject my decision, which is ok in the  
> beginning  
> of a project 😉

No probs. I don’t have much experience using Rails, but I’m ok with  
Ruby and databases. I’ve seen, though, that mistakes in the database  
generally stay there forever. Hopefully unit testing will make Rails  
apps suffer less from this. I’ve seen really hideous things in  
databases, and when I ask why we have a redundant column storing  
inconsistent data with no key constraints defined on it, the answer  
usually goes “no idea, but it works and who knows how many features  
will break if we remove it”.

Ashley