On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun <[email protected]> wrote:
> > I looked into this today with 1.5 hitting and working on a project and > this seemed relevant. > > On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote: > >> 1. A specification of the minimal useful interface for a User (perhaps >> >> in the form of an abstract base model?) >> > A User should not require a username. Usernames are a hideous remnant that > are impossible to justify on consumer facing websites. Authentication on > e-mail should be built-in if not the default. > > A user *doesn't* require a username. It requires a unique identifying field. However, by default, for historical reasons, the Django's built-in User model has a username field. The whole point of the new feature is that specifying an alternative is now a simple activity. > 4. A migration path that meets our backwards-compatibility standards. >> > I saw the configurable User model that just landed in 1.5 but for a > non-library developer this is not very useful. It looks like a very large > amount of code for a rather small function. > It's not clear what you're suggesting here. Django has a built in User model. That hasn't changed. You can now specify your own User model, and reuse large parts of Django's built in parts if that is helpful in your circumstances. What exactly is your concern here? > Furthermore: “If you intend to set > AUTH_USER_MODEL<https://docs.djangoproject.com/en/1.5/ref/settings/#std:setting-AUTH_USER_MODEL>, > you should set it before running manage.py syncdb for the first time.” is > somewhat prohibitive to existing projects. “you may need to look into > using a migration tool like South <http://south.aeracode.org/> to ease > the transition.” is not really a solution unless it is obvious what > changes should be made. > Well, this is a situation where we can't provide documentation, because everyone's specific circumstances will be different. The best advice for custom user models is "set it before you run syncdb", which is what we've said. If you've already run syncdb, you'll need to migrate your models… but exactly what that entails will entirely depend on what your own project has done. > Also I don't understand: “This example illustrates how most of the > components work together, but is not intended to be copied directly into > projects for production use.” Code that is ready for production is the > point of the documentation for me. If this isn't, I think it's a > documentation bug. > The point of that comment is that you shouldn't treat the documentation as a cargo-cult, just copying and pasting. What is there will *work*. However, in a real application, you need to pay attention to error messages, validation conditions and so on. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
