Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

On Monday 10 November 2003 21:41, Luke Opperman wrote:
> I'm a little unclear whether by superset mappings you are referring to
> Python class inheritance, or a more generic concept that happens to often

It's a more generic terminology.

> be modelled by OO inheritance. Part of the question, we've looked briefly
> at various ways of modeling inheritance, and currently take the approach of
> "one table for every concrete class, no shared attributes". This does
> ignore the possibly handy person.areas example you give, but doesn't have
> to make any guesses about what the coder meant by OO inheritance.
>
> What does person.areas return? Areas, or Homes and Offices? (just curious
> to make sure I'm understanding your example correctly.)

Actual concrete objects. So, you can either do SELECT's across all tables that 
extend Area to find the objects, or you can be more clever:

person.getAreas("Home")

to tell SQLObject that although the collection can contain any type of Area, 
you know (in this case), you've stored Home objects. Or you may just wish to 
get the Home objects. :)

> That's my key reason for agreeing with this current approach: Python (and
> most other OO languages) don't make a distinction between the various uses
> for inheritance, so let's not make a guess. :) So then, do we 'extend'
> python syntax to say "Home.subsetOf(Area)" and say that we always map that
> as your foreignKey representation? Doesn't sound half-bad to me, but there
> are alternate ways to represent it, and gets back to the
> magic-representation guessing I'd rather avoid.

But without it you get inefficent mappings, as I've highlighted.

If I had large structures, such as:

Item
   (has unique id, primary key, which we refer to for tedious reasons within 
the code, say for storing unique files associated with each Item)

Channel extends Item
   (has unique field specifying a channel id)
Periodic extends Channel
NonPeriodic extends Channel

Meter extends Item
Meter --* Channel

Location extends Item
  (location has a unique field, say a postcode/zipcode)
Site extends Location
House extends Location

SiteGroup *--* Location

Location --* Meter

You can see that flat tables just won't work nicely. How do you express a 
unique key for both Periodic and NonPeriodic channels? 

The inheritence is of vital importance in some designs. 'Superset' mapping 
isn't always the answer, as it can be inefficient, but once you get past 
noddy examples it's absolutely obvious.

There's a nice write up of mapping techniques here:

http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html



John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info