Re: [SQLObject] Join tables

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

On Tuesday 11 November 2003 17:30, Luke Opperman wrote:
> But as in all opensource projects, who's going to code these things?
> Someone with the itch.

I might have a shot, one day. It depends if I need to use Python on a much 
bigger project that means I have to try to model serious relationships ;-)

> To bring it back to the specific superset issue, I see the following
> points:
>
> a. SQLObject currently stores no information about class relationships
> (inheritance trees) except for explicit joins/fkeys.

Well it doesn't really have to. If we know B and C extend A, we can SELECT 
across tables B and C to find matching rows. Not efficient, but that's 
accepted with the type of mapping.

You (the developer) can also decide to store information. For example, in the 
Java systems I write, I have a ClassType table mapping a fully qualified 
classname to a primary key. I can then have a foreign key from a top level 
object to the ClassType table, for example:

class Thing (SQLObject):
	areas = MultipleJoin("Area")
	classType = ForeignKey("ClassType")

Therefore I can do:

areas.get(classType.get())

(or whatever syntax you'd prefer)

to get the areas inside the Collection. Assuming they are all of the same 
type.

> 1. A syntactic method for describing inheritance. Using python class
> inheritance is the obvious choice. However, that may be overloaded from
> what we're willing to implement (multiple inheritance?). Alternatively, an
> extends/derives method, although it feels less obviously pythonic.

I'd suggest multiple inheritence is a step to far, as that really does get 
very complex. I've never been sold on multiple inheritence, however people 
will want to use it (I'm sure), so adding support would be nice. Take:

class A (SQLObject):

class B (SQLObject):

class C (A, B):

We'd need to foreign keys in C (fk_a and fk_b) to support this. But this can 
be done automatically, I guess.

> Along with this comes the syntax and logic necessary to have joins of the
> Person--*Area type alternatively return subset objects (Homes/Offices), and
> reverse. (actually, reverse might already work... if you define Area to
> have a fkey to Person, both Home and Office will as well. yes.)

Something to keep in mind is we'd want to use table aliasing. Objectmatter 
'forgot' this, and as a result they've well and truely shot themselves in the 
foot as you can't do complex joins.

(Deadline to meet, /me goes back to work)


John

-- 
John Baker, Senior Developer, TEAM.
http://www.teamenergy.com
Views expressed in this mail are my own.