Re: [SQLObject] Join tables

[Luke O. <lu...@me...>]

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 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.)

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.

- Luke


Quoting John Baker <jb...@dr...>:

> On Monday 10 November 2003 20:36, Ian Bicking wrote:
> > On Nov 10, 2003, at 1:16 PM, John Baker wrote:
> > > We really need to discuss superset mappings at some point too ;-)
> >
> > What're those?
>
> class Area (SQLObject):
>
> class Office (Area):
>
> class Home (Area):
>
> SQLObject creates three tables, with a foreign key from Home -> Area and
> Office -> Area.
>
> This means I can do:
>
> class Person (SQLObject):
>   areas = ReferenceJoin("Area"...)
>
> and map a Person to a number of Areas, without having to map him to Office
> and
> Home via two join tables.
>
> Someone said superset mapping wouldn't be happening, which is a shame, as
> it's
> the most obvious and logical choice of the majority of OO mapping.
>
>
> John
>