On 06/04/2012, at 3:09 AM, Ian Lewis wrote: > The good part about swappable user models is that you don't need to > necessarily fix the model's DB fields in advance. Your identifier and > password's length and other properties can be user defined and can be > reflected in the DB. > > Django can also leave migration of user models an data up to the developer so > they an use south or whatever to manage the user model since they "own" it. > Django Devs wouldn't necessarily need to support a DB table that can > essentially never change as is the case currently. > > Fixing that stuff ahead of time and just making a FK means the user model > itself is fixed. I don't want to be able to just add fields. I want to be > able to change the primary key to be a uuid, or a email, or use the default > auto incrementing integer. I want to be able to use an existing model or DB > table and, with some work, plug it into Django auth. > > Now if I'm customizing the user model itself anyway, why not just tack on > whatever other fields I want? I don't need a FK since those fields are on the > user model and I can create however many one to one or one to many > relationships for "profiles" or user data as makes sense for my project. That > may be a lot or it may be zero. > > (now whether that is realistic given the needs of the admin is a different > story)
But I still don't see how a swapped in `User` model which *has* to behave in a specified way so that it can work with the Django admin and any other pluggable apps that might have special requirements, is any better than simply allowing the admin and other pluggable apps to have their profile and authentication needs self-contained? If Django's `User` model was just a stub (without even username and password fields), and Django shipped with an abstract `BaseAuth` model with a `username` field that was email compliant and a `password` field, and corresponding `BaseAuthForm` and `BaseAuthBackend`, then user's can still create their own `User` model with literally *whatever* fields they want in it, they can use the standard auth fields, form and backend provided by Django, or roll their own. Instead of creating a custom `User` model that quacks like an admin duck, and quacks like every pluggable app that is installed as well, all they need to do is create/update an an `AdminUser` whenever their custom `User` is saved. This is explicit, the admin and other pluggable apps know where to access information that they need (from their own models), and the developer has control over how the data is kept in sync across the pluggable apps used in the project, at the project level. Cheers. Tai. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en.
