Thread: [SQLObject] Problem Creating the "Same" ForeignKey Twice
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Brad B. <br...@bb...> - 2003-10-14 17:58:38
|
Hi, I have a class like this: class Refund(SQLObject): """A transaction where somebody was given some or all of their money back for previous Purchase.""" ...[snip overriding of new and a couple class variables]... transactionID = ForeignKey('Transaction') refundedTransactionID = ForeignKey('Transaction') The first FK pointing to Transaction, represents the transaction that took place to do this refund. The second FK, also pointing to Transaction (refundedTransactionID), represents the transaction for which the refund was done. So, I need to have two FK's pointing to the same relation, each one, of course, pointing to a different row in the foreign relation (the transaction table.) When I create the refund table with only one of the ForeignKey()s present, it works fine, but if I try to create it (calling createTable) with both defined as above, I get: Traceback (most recent call last): File "lib/merchant.py", line 252, in ? class Refund(SQLObject): File "../SQLObject/SQLObject.py", line 233, in __new__ File "../SQLObject/SQLObject.py", line 503, in addColumn File "../SQLObject/SQLObject.py", line 102, in addNeedSet File "../SQLObject/SQLObject.py", line 404, in __new__ File "../SQLObject/SQLObject.py", line 662, in _init File "../SQLObject/DBConnection.py", line 254, in _SO_selectOne File "../SQLObject/SQLBuilder.py", line 126, in sqlRepr ValueError: Unknown SQL builtin type: <class 'SQLObject.SQLObject.MetaSQLObject'> for <class '__main__.Transaction'> Is there a known restriction/reason for why I can't have two FK's in A that both point to B, or is this a bug? -- Brad Bollenbach BBnet.ca |
From: Ian B. <ia...@co...> - 2003-10-14 18:05:45
|
First, are you using CVS? There's a bug in 0.4 related to this. CVS will be 0.5 once I package it up. On Tuesday, October 14, 2003, at 12:58 PM, Brad Bollenbach wrote: > Hi, > > I have a class like this: > > class Refund(SQLObject): > """A transaction where somebody was given some or all of > their money back for previous Purchase.""" > > ...[snip overriding of new and a couple class variables]... > > transactionID = ForeignKey('Transaction') > refundedTransactionID = ForeignKey('Transaction') > > The first FK pointing to Transaction, represents the transaction that > took place to do this refund. The second FK, also pointing to > Transaction (refundedTransactionID), represents the transaction for > which the refund was done. So, I need to have two FK's pointing to the > same relation, each one, of course, pointing to a different row in the > foreign relation (the transaction table.) > > When I create the refund table with only one of the ForeignKey()s > present, it works fine, but if I try to create it (calling > createTable) with both defined as above, I get: > > Traceback (most recent call last): > File "lib/merchant.py", line 252, in ? > class Refund(SQLObject): > File "../SQLObject/SQLObject.py", line 233, in __new__ > File "../SQLObject/SQLObject.py", line 503, in addColumn > File "../SQLObject/SQLObject.py", line 102, in addNeedSet > File "../SQLObject/SQLObject.py", line 404, in __new__ > File "../SQLObject/SQLObject.py", line 662, in _init > File "../SQLObject/DBConnection.py", line 254, in _SO_selectOne > File "../SQLObject/SQLBuilder.py", line 126, in sqlRepr > ValueError: Unknown SQL builtin type: <class > 'SQLObject.SQLObject.MetaSQLObject'> for <class > '__main__.Transaction'> > > Is there a known restriction/reason for why I can't have two FK's in A > that both point to B, or is this a bug? > > -- > Brad Bollenbach > BBnet.ca > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: Brad B. <br...@bb...> - 2003-10-14 18:17:07
|
On Tuesday, October 14, 2003, at 02:05 PM, Ian Bicking wrote: > First, are you using CVS? There's a bug in 0.4 related to this. CVS > will be 0.5 once I package it up. Yep, just updated SQLObject a moment ago right from SourceForge to be double-sure. Same bug. -- Brad Bollenbach BBnet.ca |
From: Ian B. <ia...@co...> - 2003-10-14 18:21:36
|
On Tuesday, October 14, 2003, at 01:17 PM, Brad Bollenbach wrote: > On Tuesday, October 14, 2003, at 02:05 PM, Ian Bicking wrote: > >> First, are you using CVS? There's a bug in 0.4 related to this. CVS >> will be 0.5 once I package it up. > > Yep, just updated SQLObject a moment ago right from SourceForge to be > double-sure. Can you double-check the installation? I definitely remember this bug showing up with this exact same sort of exception in the past. If that doesn't help, I won't be able to look at this until tonight. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: Brad B. <br...@bb...> - 2003-10-14 18:29:23
|
On Tuesday, October 14, 2003, at 02:21 PM, Ian Bicking wrote: > On Tuesday, October 14, 2003, at 01:17 PM, Brad Bollenbach wrote: >> On Tuesday, October 14, 2003, at 02:05 PM, Ian Bicking wrote: >> >>> First, are you using CVS? There's a bug in 0.4 related to this. >>> CVS will be 0.5 once I package it up. >> >> Yep, just updated SQLObject a moment ago right from SourceForge to be >> double-sure. > > Can you double-check the installation? I definitely remember this bug > showing up with this exact same sort of exception in the past. If > that doesn't help, I won't be able to look at this until tonight. Ugh, I had a custom (older, of course) version of SQLObject living in the same directory as the relevant module being imported, so even though the CVS version of SQLObject was in the first directory in my PYTHONPATH, it was never getting seen. Moved that version out of the way so that the CVS version gets seen, and it Does The Right Thing now. I could use a dark corner to crawl into right now. -- Brad Bollenbach BBnet.ca |