Re: PyDO2 inheritance ..

On Fri, Jun 03, 2005 at 11:45:08AM +1000, Steve Kieu wrote:
> 
> Hi,
> 
> Reading the docs I understand that inheritance is
> possible. My case is like this:
> 
> a table person(id,name,email)
> a table staff(id, start_date)
> 
> staff.id is foreign key of person.id, and also primary
> key.
> 
> mapping to object
> 
> class person(PyDO):
>   table='person'
>   fields=(Sequence('id'),'name','email')
> class staff(person):
>   table='staff'
>   fields=(Sequence('id'),'start_date')
> 
> However if I call 
> 
> staff.new(id=1,start_date='2001-01-03',name='Test',email='email')
> 
> it does not work, and complain that name and email is
> Unknown column email.
> 
> I think I did something wrong but not figure it out
> what, please help.

In your example, you would get:

  >>> person.getColumns()
  ['email', 'name', 'id']
  >>> staff.getColumns()
  ['id', 'start_date', 'email', 'name']

I hope that reveals what the problem is; by making staff a subclass of
person, you are getting columns in your object that aren't actually in
the staff table.  So you don't want to use inheritance to model this
relationship; to deal with the foreign key you would add a getPerson()
instance method to staff that returns person.getUnique(id=self.id).

The relevant fact is that when you inherit from PyDO classes, your new
class gets the sum of all the fields of its bases classes -- *unless*
you create your subclass by calling project().

So the use cases of inheritance are a little different than you
imagined.  If you are using postgresql, you might have table
inheritance in your database, in which case the correspondence between
the dbms feature and PyDO's inheritance is largely exact (except that
postgresql doesn't automatically inherit pk constraints and indexes,
which you normally want and have to do manually, and PyDO unique
constraints are inherited).  Otherwise, you might have tables in any
database that share sets of columns, and you want to define them only
once; or have a mutable version and an immutable version of the same
class, one pointing to a view and the other to a table.  It isn't a
useless facility to have, but neither is it anything that will do
wonders for you.

In this case, for these little tables, inheritance just isn't
accomplishing anything, so I wouldn't do it.

Of course, you can use inheritance for things besides fields.  I
usually define a base class for all the tables in a database with the
attributes I want shared (connectionAlias, schema).  Note that
"guess_columns" does *not* work this way; you can't declare it in a
base class (the metaclass only acts on this declaration if the
declaration is made in the current class namespace).

Cheers,

js

-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCn7/CuqamFyFXXLIRApt8AJ4oJfoR1onhrNxeIAwdjwjhmx7vdgCfbcuy
UlH6oJOgtOP+r41ViLZTKF4=
=BAjn
-----END PGP SIGNATURE-----