Re: [SQLObject] Re: SQLObject

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

Okay, I got all confused because both of your first and last names start
in B, and when I was first skimming through this I thought one of you
was arguing with yourself.  But no... anyway, to interject, I still
don't feel there's a good use case for multiple keys (except legacy
schemas)

On Fri, 2003-04-11 at 08:44, Bud P.Bruegger wrote:
> If this is your comments table, there are no problems.  However, the
> problem I try to illustrate uses the following table:
> 
> CREATE TABLE ProjectWorkerComment(
>   project_id INT,
>   worker_id INT,
>   comment_id INT,
>   PRIMARY KEY (project_id, worker_id, comment_id),
>   FOREIGN KEY (project_id, worker_id) REFERENCES ProjectWorker);

In this example you should have a join, in the spirit of RelatedJoin. 
Project would have a workerComment method that would return a list of
(worker, comment) tuples, and Worker and Comment would have similar
methods.

So long as a table only contains references to other tables, it should
be represented by a Join of some sort, the rows of that table should not
be Python objects.  After looking through examples, I feel increasingly
confident that this intuition is correct -- rows without content of
their own are derivative, and should be treated as such.

  Ian