[Nitro] Og inheritance

Jonathan Buch john at oxyliquit.de
Thu Sep 14 07:11:50 EDT 2006


> Name collisions are a problem in OG inheritence.
> class A
>   property   :foo, String
>   schema_inheritance
> end
> class B < A
>   property   :bar, String
> end
> class C < A
>   property   :bar, Integer
> end

I think that is a bad idea (at least from the DB point of view).

> I wonder if one is better off not using schema_inheritance and instead
> letting it create a table per class.
> What are the pros and cons?

Well, to handle schema inheritance Og uses STI, single table inheritance,  
is one possibility to handle the situation of inheritance.  I personally  
that it's a bad idea and confusing to name differing properties in  
the same.  Are you trying to make some kind of ducktyping possible here?

I would propose to rename the properties, or at least the fields to the

class B < A
   property :bar, String, :field => 'bar_string'
class C < A
   property :bar, Fixnum, :field => 'bar_int'

This way you won't have to go away from STI but still have the 'type
independand' access.

You could also move the property up to `class A` using String as property  
encode/decode stuff by using YAML.

class A
   is Og::SchemaInheritanceBase
   property :foo, String
   property :bar, String
class C < A
   property :bar, String
   def bar
     return YAML.load(@bar)
   def bar=(b)
     raise(TypeError, 'C only saves integers') unless b.kind_of?(Integer)
     @bar = YAML.dump(b)

You get the drift.

Good?  Maybe.

I wouldn't dare to weigh pros and cons of STI here without knowing exactly
where the problem and usecase of your specific appliaction is.  As you can
see, with Og you can always get around problems very easily.  No need to
change ones view to 'no inheritance' when inheritance seems the right way.


Feel the love

More information about the Nitro-general mailing list