I've come across (or rather created:-/) a similar, but more interesting situation as Robin. Before I upgraded to 0.9a, I wrote a User class in 0.89, which had many similar fields as TG_User. In theory it makes sense to just factor those fields into a class that extends TG_User; which I did, altho this ended up creating a mostly empty User table, as most my added fields are MultipleJoins that create no field in the User table. One field was a ForeignKey to my Email table (this system stores multiple emails per user), this would conflict with/obsolete the emailAddress field in TG_User, making it redundant and useless to me.
Also (yes there is more) I have another table for a different kind of user, which has another set of information ontop of User. It would make sense for this class to inherit User, thereby creating yet another table, that represents a grandchild of TG_User. My question: is this overkill? should I forget the inheritence and just do a one-to-one relation instead? it would seem to make much less of a mess out of my tables. Sean Jamieson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
