On Monday 27 April 2009 21:17:44 Malcolm Tredinnick wrote: > On Mon, 2009-04-27 at 21:11 +0200, Emmanuel Surleau wrote: > > On Monday 27 April 2009 20:12:13 karl wrote: > > > > Apologies in advance, I'm sure this query pops up regularly. > > > > > > > > I'd like to replace the default User class which comes with Django's > > > > authentication system (for my application, users login via > > > > email/password, not login/password, so it's not only a matter of > > > > adding fields). > > > > > > > > Is there an easy way to do it? Or should I just roll my own and give > > > > on the default authentication system and (sniff) admin site? > > > > > > This blog article explains it simply and has ready-to-use code: > > > > > > http://www.davidcramer.net/code/224/logging-in-with-email-addresses- in- > > > > djan > > > > >go.html > > > > Very nice and useful. However, it suffers from a simple flaw: the default > > Django user model does not guarantee the uniqueness of email addresses, > > which is a problem when you need it as primary key. > > Non-uniqueness is a consideration, but your conclusion doesn't follow. > You don't need it as a primary key for what you're doing. and creating a > new model won't solve the bulk of the problem. You do want to check that > the email address is unique and that's a matter of doing so at form > creation time. Django doesn't currently have any level of model-field > validation, so this has to be checked in the form in any case (or in the > code that is creating the user).
I'm aware of this. I'm more concerned about data integrity. > You can certainly do an "alter table" on your database to add the > uniqueness constraint to the column if you want to make sure no > non-unique entries are inserted. That doesn't require a model change. If > you're creating a form to enable users to specify their details, > manually specify that the email (form) field should have unique=True. If > you're doing it via code (e.g. calling User.objects.create_user()), > check for uniqueness first -- creating a new or different model won't > help you there in any case, so it's not creating any extra work. The advantage of having the uniqueness specified in the model is that you get it "for free" with syncdb. At the same time, I'm migrating from another framework (and DBMS), so I'll get to write SQL to port the data to Django anyway. So maybe you're right and I'm worrying too much about details. Thanks, Emm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
