On 3 April 2012 04:56, Alex Ogier <alex.og...@gmail.com> wrote: > I get that Django's core is very accustomed to the relational database mode > of thinking: "If a User might own a Twitter handle, then let's create a > table of twitter handles in the twitter-auth app, and foreign key back to > the default User model". It's really not that bad to go the other way for a > moment, and say "If a User might own a Twitter handle, then let's add a > twitter_handle field to Users."
What if the User owns more than one Twitter handle? I use six different email-addresses regularly and several openids. The auth backends I write use Foreign Key and not OneToOneKey back to User for a reason. > The reason being that the latter is *so much > more flexible*. You can simulate the first with the second, but not vice > versa. Twitter-auth might not need its own table (in fact, it shouldn't need > its own table). If you really wanted to, you could make one, and foreign-key > *from* the user model which gives you everything the first solution has, > with no need to created magical .prof1, .prof2 proxy attributes. You could > even let users sign in with multiple handles with a many-to-many. Heck, > maybe your blog posts have their own twitter credentials, I don't know. This would *only* be flexible with a many-to-many. Then you wouldn't have to ALTER TABLE to add an auth-backend. HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
