check the docu
Cheers
On Wed, Feb 27, 2013 at 1:15 PM, Eric Psalmond <epsalmond@gmail.com> wrote:
Hi everyone,After a bit of searching I didn't find an answer to this issue, so I thought I'd post here and see what the response was like.A little background: I've been working with other frameworks and packages for years - from Websphere long ago to RoR and M$-MVC more recently.After using Django for about two weeks I'm 100% in love with it and have been singing its praises from the mountaintops. Documentation is dead on and unlike anything else I've seen, and the ORM is for people that actually understand and like RDBMS, and in a day and age of No-SQL fads and PHP "developers," it has been very refreshing. I was trying out Django alongside with a trendy new PHP framework that claimed to have great docs and ORM, but when implementing it I found it was a typical mess of documentation-by-forum and uniquely seemed to love the smell of its own farts more than any open source project I'd ever seen.If I had one complaint about Django, it would be lack of support for composite keys, but I see enough work has already been done on that front that I might feel comfortable hacking something together, and it's so minor compared to all the other benefits that I can live with it.Anyway- on to my question:I rolled a custom user model since 1.5 was released yesterday. I love the abstractions of AbstractUser and AbstractBaseUser, it totally makes sense. However, when I rolled my own custom user class and tried to use the built in UserAdmin and UserCreationForm classes, I had a problem with the Admin. Everything in my project seemed to obey the swappable Meta tag in the User class except for the UserCreationForm. I always got an error of: Table does not exist: "auth_user" whenever getting past the first step of setting username and password.Not being super familiar with forms in Django yet, I stepped through the debugger and found that this line in the form was the culprit:def clean_username(self):# Since User.username is unique, this check is redundant,# but it sets a nicer error message than the ORM. See #13147.username = self.cleaned_data["username"]try:User._default_manager.get(username=username)except User.DoesNotExist:return usernameraise forms.ValidationError(self.error_messages['duplicate_username'])For some reason, User._default_manager.get refused to obey the switch the my CustomUser class. User.anything_else seemed to be OK. I resolved this by changing User._default_manager.get to my CustomUser._default_manager.get and now everything is peachy and going to the right table.I have seen some posts that indicate when using a custom user class that new forms and UserAdmin classes must be rolled (or, *gasp*, copy-pasted,) so I'm wondering if this is the expected and correct behavior, am I missing something, or did I find a bug?Thanks for reading and I look forward to participating in this awesome community.Best,-Eric--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment