Thread: [SQLObject] Foreign Key naming
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Andres F. <an...@an...> - 2005-11-29 11:04:40
|
Hi, Im using sqlobject in combination with sqlos and im a mostly happy user except one issue: I have an existing database so i cant change the naming style of that. The problem is, that columns referring to other tables are named like this: table_name_id. If i define that to be a foreign key it generates a variable name line table_name_ which i find ugly, especially as they occur in my interface. Is there any reason why this is hardcoded (col.py line 182(in trunk)/181)? Beside that no one changed it so far (which is a valid reason, but I will change it myself then). Because i would like to change this, but i dont see any way, to get around this naming. Andres Freund |
From: Ian B. <ia...@co...> - 2005-11-29 23:17:44
|
Andres Freund wrote: > Im using sqlobject in combination with sqlos and im a mostly happy user > except one issue: > I have an existing database so i cant change the naming style of that. > The problem is, that columns referring to other tables are named like > this: table_name_id. If i define that to be a foreign key it generates a > variable name line table_name_ which i find ugly, especially as they > occur in my interface. > Is there any reason why this is hardcoded (col.py line 182(in > trunk)/181)? Beside that no one changed it so far (which is a valid > reason, but I will change it myself then). Because i would like to > change this, but i dont see any way, to get around this naming. It's not really intentional. There's a patch related to this (at least generally) that might resolve this issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1353728&group_id=74338&atid=540674 -- I haven't had a chance to really look at it yet, I'm afraid, but if everything looks good it should go in. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Andres F. <an...@an...> - 2005-11-30 14:23:26
|
Hi, Ian Bicking wrote: > It's not really intentional. There's a patch related to this (at > least generally) that might resolve this issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1353728&group_id=74338&atid=540674 > -- I haven't had a chance to really look at it yet, I'm afraid, but > if everything looks good it should go in. Ok, i looked through the patch and applied it. It works, but has a shortcoming. If you define a foreignKey via some_id = SomeCol(..., foreignKey="some") it want to name the foreignKey also as some_id. Which is bad i think. The good thing is, that now you just have to change one line to change the name of the generated variable. To get the old behaviour i had to change this (new col.py line 214): # this is in case of ForeignKey, where we rename the column # and append an ID self.origName = origName or name into this: # this is in case of ForeignKey, where we rename the column # and append an ID self.origName = origName or name[:-2] Yes, this is still not very nice, but it works with the old ids, and is easier to change. And it should be easy to change this into an Style method. For now i had to change id to -3 to work with my scheme, but if you think this should be Style thingie i will make a patch up for it. My current problem is, that i don't see when the origName is directly provided, so i don't know if it has to get changed too. Perhaps i will find some time to look further into it. Andres Freund PS: Sorry Ian, for sending it directly to you, i have another email client at work than at home, so my customized keybindings didnt work. |