Re: [SQLObject] Re: SQLObject

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

On Thu, 2003-04-10 at 18:22, Brad Bollenbach wrote:
> On 04/10/03 01:06, Ian Bicking wrote:
> > On Thu, 2003-04-10 at 00:38, Edmund Lian wrote:
> > > Composite keys are used an awful lot in any schema of moderate complexity,
> > > and they are important (when used with foreign key constraints) for
> > > enforcing relational integrity. If the aim is for SQLObject to support
> > > complex projects, then composite key support would be pretty important.
> > 
> > Can you describe some situations where they'd be used?  For instance, if
> > either key was modified at any time that'd cause a lot of problems for
> > SQLObject.  If not, then what would be the problem with a third simple
> > ID/PRIMARY KEY column?
> 
> I use concatenated keys all the time.
> 
> e.g.
> 
> Site
> site_id PK
> ...
> 
> User
> user_id PK
> ...
> 
> UserSite
> user_id	FK
> site_id FK 
> (together they're the PK)
> ...

This seems like a many-to-many relation, which SQLObject doesn't
represent as a Python object, and which doesn't require any ID.  

> The problem with not having complex primary key support is not that it
> makes it impossible to write a certain kind of application but that it
> creates extra unnecessary, boring work for the programmer to have to
> hardcode the validation checks (and the unit tests for them) to ensure
> -- taking from one example above -- that a user hasn't been granted
> access to a site twice.

But you can still declare the composite columns to be unique with them
being the primary key.  If it's a table that's really as derivitive as
these, I don't think the rows should be represented as Python objects. 
If RelatedJoin doesn't work like you'd need, maybe a different join
should be made, but I think that's where tables like UserSite belong.

  Ian