Thread: [SQLObject] sqlobject doesn't create foreign keys with MySQL?
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Matthew W. <ma...@tp...> - 2006-10-25 14:25:15
|
I'm running a MySQL database and I set the default table type to InnoDB, which supports foreign keys. I created the following two tables, ran the sql, and then discovered that the foreign keys were not in the database: class Temple(SQLObject): templename = UnicodeCol() members = MultipleJoin('Member') class TempleMember(SQLObject): mobilenumber = StringCol(length=20) membername = StringCol() temple = ForeignKey('Temple') I ran the sql by using the turbogears tg-admin sql create tool. What am I doing wrong? TIA Matt -- A better way of running series of SAS programs: http://overlook.homelinux.net/wilsonwiki/SasAndMakefiles |
From: Oleg B. <ph...@ph...> - 2006-10-25 14:36:12
|
On Wed, Oct 25, 2006 at 02:18:40PM +0000, Matthew Wilson wrote: > I created the following two tables, ran the sql, and then discovered > that the foreign keys were not in the database: Foreign key constraints will be implemented in SQLObject 0.8. You can try SQLObject from the SVN trunk. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2006-10-26 06:18:50
|
On Wednesday 25 October 2006 17:36, Oleg Broytmann wrote: > On Wed, Oct 25, 2006 at 02:18:40PM +0000, Matthew Wilson wrote: > > I created the following two tables, ran the sql, and then discovered > > that the foreign keys were not in the database: > > Foreign key constraints will be implemented in SQLObject 0.8. You > can try SQLObject from the SVN trunk. Will it be possible to still use the current capability of SQLObject to use foreign keys even on tables that are not capable of such thing internally (like with mysql's myisam tables)? In other words my question is if this new database key constraint implementation will replace the current behavior or will they both be available? I agree that the current behavior is less efficient as it has to do all the work internally and involves a lot of sql queries to perform a cascaded delete for example but it works on any type of database even if it doesn't support key constrains, so having it around for such cases would still be useful. -- Dan |
From: Oleg B. <ph...@ph...> - 2006-10-26 09:22:25
|
Hello. On Thu, Oct 26, 2006 at 09:18:36AM +0300, Dan Pascu wrote: > Will it be possible to still use the current capability of SQLObject to > use foreign keys even on tables that are not capable of such thing > internally (like with mysql's myisam tables)? A hard question. I would say "yes", but that require more testing. One needs at least to create tables without applying constraints: MyTable.createTable(applyConstraints=False) and ignores the returned constraints. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2006-10-26 10:06:37
|
On Thursday 26 October 2006 12:21, Oleg Broytmann wrote: > Hello. > > On Thu, Oct 26, 2006 at 09:18:36AM +0300, Dan Pascu wrote: > > Will it be possible to still use the current capability of SQLObject > > to use foreign keys even on tables that are not capable of such thing > > internally (like with mysql's myisam tables)? > > A hard question. I would say "yes", but that require more testing. > One needs at least to create tables without applying constraints: > MyTable.createTable(applyConstraints=False) and ignores the returned > constraints. What about defining this new functionality using a different column type, say SQLForeignKey or DBForeignKey? Then both can be available at the same time and used as the case requires. -- Dan |
From: Oleg B. <ph...@ph...> - 2006-10-26 10:23:27
|
On Thu, Oct 26, 2006 at 01:06:24PM +0300, Dan Pascu wrote: > What about defining this new functionality using a different column type, > say SQLForeignKey or DBForeignKey? It would be much harder to support both column. A lot of new code required. Do you want to work on this? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2006-10-26 10:42:53
|
On Thursday 26 October 2006 13:23, Oleg Broytmann wrote: > On Thu, Oct 26, 2006 at 01:06:24PM +0300, Dan Pascu wrote: > > What about defining this new functionality using a different column > > type, say SQLForeignKey or DBForeignKey? > > It would be much harder to support both column. A lot of new code > required. Do you want to work on this? I'm currently just exploring possibilities, but I guess you're right about the complexity. The point is to have both available but not inside the same table so a different column type wouldn't make much sense. So the original idea of having an applyConstraints per table seems fair enough. All I want to see is the current functionality preserved as I use it with tables where foreign keys are not supported and I benefit from SQLObject doing the job itself without the database help. OTOH I really appreciate the fact that native database support for foreign keys is to be implemented for the databases that support this, as this will improve the performance significantly. -- Dan |