Re: [SQLObject] foreign key, string vs. object, circular references...

Hmmmm indeed. I really don't like a solution that makes maintaining
tablenames more than just editing the specific class. And I wouldn't
like to have to support this list hack in the future when we have a
better method. So for now, I'd say hold off on being able to create
with the "references" SQL.

(Admittedly, our use of SQLObject is leading to moving constraints
like 'references' out of the database and into SQLObject. So it's
less of an issue to me. But at the same time, a 'references'
constraint has only ever been truly useful to me if i'm also able to
set "ON DELETE/UPDATE ...", which i'm not sure how you're going to
get into SQLObject right now.)

- Luke

> Hmmmm..  So what about a not overly elegant solution to createTable
> with foreign keys that works for the time being.  Something like:
>
> In Col.py, _extraSQL:
>
>
>  if self.foreignKey:
>     if type(self.foreignKey) == type([]):
>       foreignTableSQLName = foreingKey[1]
>     else:
>       foreignTableSQLName = SQLNameFromClassName(self.foreignKey)
>     result.append('REFERENCES %s') % foreignTableSQLName