Re: [SQLObject] SQLObject's inheritance patch

[Ian B. <ia...@co...>]

Daniel Savard wrote:
>     Here is a patch that add simple inheritance to SQLObject 0.8.1.
>     If you try it, please send me some comments (to the list or my 
> email).  Thanks.

Thanks for contributing this.  It looks like it required less 
modifications than I expected.  One thing I wondered about: will this 
work with the addColumn class method?  It doesn't seem like it -- the 
inheritance structure seems to be constructed entirely at the time of 
class instantiation.  To do this, superclasses would need to know about 
all their subclasses, so they could add the column to subclasses as well.

>     A new class attribute '_inheritable' is added.  When this new 
> attribute is set to 1, the class is marked 'inheritable' and two colomns 
> will automatically be added: childID (INT) and childName (TEXT).  When a 
> class inherits from a class that is marked inheritable, a new colomn 
> (ForeignKey) will automatically be added: parent.

Is childID needed?  It seems like the child should share the parent's 
primary key.

>     The column parent is a foreign key that point to the parent class.  
> It works as all SQLObject's foreign keys.  There will also be a parentID 
> attribute to retreive the ID of the parent class.
> 
>     The columns childID and childName will respectivly contain the id 
> and the name of the child class (for exemple, 1 and 'Employee'.  This 
> will permit to call a new function: getSubClass() that will return a 
> child class if possible.

These seem weird to me, but I think that's the disconnect between RDBMS 
inheritance (which is really just another kind of relationship), and OO 
inheritance.

I'd rather see Person(1) return an Employee object, instead of having to 
use getSubClass().  Or, call getSubClass() simply "child", so that 
someEmployee.child.parent == someEmployee.

But at that point, it really doesn't look like inheritance.  Rather we 
have a polymorphic one-to-one (or one-to-zero) relation between Person 
and Employee, and potentially other tables (exclusive with the Employee 
relation).  The functional difference is that the join is in some ways 
implicit, in that Employee automatically brings in all of Person's 
columns.  At which point Employee looks kind of like a view.

Could this all be implemented with something like:

class Person(SQLObject):
     child = PolyForeignKey()
     # Which creates a column for the table name, and maybe one for the
     # foreign ID as well.

class Employee(SQLObject):
     parent = ColumnJoin('Person')
     # ColumnJoin -- maybe with another name -- brings in all the columns
     # of the joined class.

This seems functionally equivalent to this inheritance, but phrased as 
relationships.  And, phrased as a relationship, it's more flexible.  For 
instance, you could have multiple ColumnJoins in a class, without it 
being very confusing, and multiple PolyForeignKeys, for different 
classes of objects.

   Ian