Re: [SQLObject] Re: SQLObject

[Bud P. B. <bu...@si...>]

On 10 Apr 2003 00:23:11 -0500
Ian Bicking <ia...@co...> wrote:

> I hope you don't mind me copying you to the list.
> 
> On Wed, 2003-04-09 at 04:15, Steve Holden wrote:

....

> > 4. The whole business of using "id" as a default name for a primary key is
> > somewhat contrived, and increases the difficulty of mapping SQLObject onto
> > existing database schemas.

For what it's worth, here are some thoughts on the topic.  

I personally believe having id's is a great thing.  Using primary keys
with any sort of business meaning will get you into trouble sooner or
later.  So if SQLObject didn't add it, I would...  (BTW, this argument
is also relevant for composite keys--they usually have business
meaning...).  The only problem may occur if one uses SQLObject with
pre-existing databases that don't have a comparable field...

Correct me if I'm wrong, but it seems that SQLObject needs an id
column of type integer.  Could that be relaxed to be another type (a
string).

In this case, one possible solution would be to use an option
"primaryKey=True" for Col.  If a primary key is defined in _columns,
then it is used, else, id is implied as is currently the case.  

Another thought in this context is that PostgreSQL already inserts an
object id column for every table.  But maybe it's not a good idea to
use since other dbms don't have equivalents...

One thing on my wishlist would be to (optionally) create a globally
unique id for the object.  That could be controlled by an additional
option "globallyUnique=True" that would go together with PrimaryKey,
Unique, or alternateID (i.e., everything that implies Unique).  

> > 7. I don't see any support for tables with composite primary keys. Is this
> > an omission you plan to rectify?
> 
> I don't know.  I like single, simple primary keys.  They work well.  If
> the table is really so minimal that it can't stand to have an extra
> field for the id, then I suspect a SQLObject class is too heavy for it
> (like with the join tables).  Of course, when adapting to a pre-existing
> schema you might not have as many options.  Maybe it wouldn't be that
> hard to fudge it (maybe make the ID into a tuple), but SQLObject really
> expects for each object to have a single ID.

For the above considerations, I think a single object id is usually a
good idea.  In one project I started out with composite keys and as
the data structure evolved added an autoincrement key to keep it
simpler and more changeable.  

However, it may be nice to have composite field indices on tables and
have an equivalent to alternateID that creates a method with multiple
arguments.  

cheers

-bud