|
From: SourceForge.net <no...@so...> - 2008-02-03 18:06:05
|
Bugs item #1885802, was opened at 2008-02-03 18:59 Message generated for change (Comment added) made by tmaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1885802&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: SQLObject release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Till Maas (tmaas) Assigned to: Nobody/Anonymous (nobody) Summary: SQLObject should determine joinColumn from Class Name Initial Comment: Currently SQLObject determines the joinColumn for MultipleJoin from the name of the table. In the documentation it is recommended to use "user_table" as a table for an class called User. When one now creates another class, e.g. Address that has a ForeignKey from User in a column called "user", one needs to add joinColumn='user_id' to the MultipleJoin definition within the User class, otherwise one only gets a totally strange python traceback, when one tries to access u.addresses. I attached a simple example, that makes it more clear, where the problem here is. I use python-sqlobject-0.9.2-1.fc7 from Fedora. ---------------------------------------------------------------------- >Comment By: Till Maas (tmaas) Date: 2008-02-03 19:06 Message: Logged In: YES user_id=60606 Originator: YES Even better would be, if it was possible to use: addresses = MultipleJoin(Address.user) and then SQLObject would determine by itself whatever the column_id of Address.user is, without the user of SQLObject needing to know how the internalf of SQLObject work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1885802&group_id=74338 |
