convore.json/groups/django-community/customizing-your-user-model/messages.json

[{"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298133598.2496569, "message": "Most projects I've seen use get_profile() to return a custom UserProfile model.It always struck me as a nasty hack, requiring an extra db call or join, especially if you just need a few extra fields. What other solutions do Django people use here for customizing their User model ?", "group_id": 81, "id": 149824}, {"user_id": 13865, "stars": [], "topic_id": 7489, "date_created": 1298134290.1671309, "message": "You will probably use applications that refer to auth.User as foreign key, so you can't get rid of it. Only way to do what you want without extra request/join is some nasty replacement of auth.User (ie. monkey patching or something like that).", "group_id": 81, "id": 149843}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298136385.4276659, "message": "Until Django adds a generic UserField which can be repointed, profile modules are the best of several bad options. If you are worried about query perf, just shove it all in a cache.", "group_id": 81, "id": 149957}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298138600.0185571, "message": "@danjac I think one of the general goals for 1.4 is to review \"pluggable apps\" and figure out how to improve them. The User model issue is one of many that make writing generic apps somewhat harder than it should be. @alex gave a good talk on it at the last Djangocon IIRC.", "group_id": 81, "id": 150063}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298136966.4959331, "message": "Is a generic UserField (or better, generic ForeignKey) on the Django roadmap ?", "group_id": 81, "id": 149994}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298139515.5591979, "message": "@danjac I don't think it is as bad as you are making it out to be. At least in our apps it hasn't been a problem either on design or performance.", "group_id": 81, "id": 150100}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298139048.826405, "message": "@coderanger: that would be a positive development, the current UserProfile hack is something that should have been deprecated some time ago IMHO.", "group_id": 81, "id": 150089}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298139818.681227, "message": "@coderanger: having to  do an extra db call or an extra join just because you need another field or two is a poor solution. It's something that's bugged me about Django for years.", "group_id": 81, "id": 150113}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298140183.030061, "message": "@danjac Compared to the 20 queries that the rest of the page runs (which are usually far more complex too) it isn't a big deal. The one thing we did do to make life a bit easier it to install a lazy callback as \"request.profile\" to use instead of \"request.user.get_profile()\".", "group_id": 81, "id": 150117}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298140790.504091, "message": "@coderanger: I do the same, along the same lines as the LazyUser pattern.", "group_id": 81, "id": 150126}, {"user_id": 9650, "stars": [], "topic_id": 7489, "date_created": 1298145836.172693, "message": "Customizing with a O2O relationship to a UserDetails model isn't that bad in my opinion.  I had a hard time recently to decide whether I should use inheritance or ModelDetails for some sort of extension, and ended up with ModelDetails.  It may feel un-object-oriented but its the best compromise I think.  See also http://www.b-list.org/weblog/2007/feb/20/about-model-subclassing/", "group_id": 81, "id": 150417}, {"user_id": 5939, "stars": [], "topic_id": 7489, "date_created": 1298150444.7742939, "message": "What ever you do, don't subclass User. That is just asking for trouble...", "group_id": 81, "id": 150574}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298149353.5018871, "message": "The problem is that everyone agrees that there are no good options right now, nobody really likes it, yet it's been an issue for so long: http://bit.ly/4WWArs", "group_id": 81, "id": 150543}, {"user_id": 1822, "stars": [], "topic_id": 7489, "date_created": 1298151401.5143099, "message": "@coderanger Is this request.profile technique outlined somewhere in a blog post or somewhere? Sounds interesting (maybe it's simpler than I'm imagining)", "group_id": 81, "id": 150628}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298154639.658093, "message": "@ptone No, but it probably should be. I'll write one up tomorrow :-)", "group_id": 81, "id": 150753}, {"user_id": 719, "stars": [{"date_created": 1298161284.6078, "user_id": 1}, {"date_created": 1298161341.6867001, "user_id": 214}], "topic_id": 7489, "date_created": 1298161246.201519, "message": "http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/middleware.py", "group_id": 81, "id": 151435}, {"user_id": 2056, "stars": [], "topic_id": 7489, "date_created": 1298160406.695529, "message": "What is the LazyUser Pattern? Anyone have a link where I can read about it?", "group_id": 81, "id": 151320}, {"user_id": 214, "stars": [], "topic_id": 7489, "date_created": 1298161187.1026721, "message": "It just involves sticking a descriptor onto the request that lazily gets the user when accessed.", "group_id": 81, "id": 151423}, {"user_id": 2056, "stars": [], "topic_id": 7489, "date_created": 1298161798.247309, "message": "@carljm thanks. will do", "group_id": 81, "id": 151481}, {"user_id": 214, "stars": [], "topic_id": 7489, "date_created": 1298161123.2989309, "message": "@pyeek grep the Django source for LazyUser.", "group_id": 81, "id": 151417}, {"user_id": 214, "stars": [], "topic_id": 7489, "date_created": 1298161202.1139679, "message": "contrib/auth/middleware.py", "group_id": 81, "id": 151427}, {"user_id": 11827, "stars": [{"date_created": 1298326958.3944061, "user_id": 14492}], "topic_id": 7489, "date_created": 1298192625.669867, "message": "Django models have an add_to_class method (using setattr) which you can use to add new fields/methods to the class. Forrsters, can find a complete example here: http://forrst.com/posts/Django_User_extra_field-4tv", "group_id": 81, "id": 152519}, {"user_id": 11827, "stars": [], "topic_id": 7489, "date_created": 1298192669.42908, "message": "Essentially something like this: from django.contrib.auth.models import User\nUser.add_to_class('birthday', models.DateTimeField(blank=True, null=True))", "group_id": 81, "id": 152520}, {"user_id": 11827, "stars": [], "topic_id": 7489, "date_created": 1298192698.4735849, "message": "You'll need to modify the admin as well (can unregister and register a new one)", "group_id": 81, "id": 152521}, {"user_id": 5296, "stars": [], "topic_id": 7489, "date_created": 1298197922.0930159, "message": "I actually worked on this in the last GSOC for django. Each app is now a class, which has a models attribute. You can, for example, subclass the Auth class and replace the user model with your own model that has your domain specific fields in it => no more get_profile", "group_id": 81, "id": 152979}, {"user_id": 5296, "stars": [], "topic_id": 7489, "date_created": 1298197961.8345311, "message": "the code still needs some work though ... :-)", "group_id": 81, "id": 152980}, {"user_id": 592, "stars": [], "topic_id": 7489, "date_created": 1298229049.723449, "message": "@coderanger That's correct.", "group_id": 81, "id": 154455}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298228747.4137819, "message": "@arthurk To be clear, that hasn't landed in trunk, right?", "group_id": 81, "id": 154444}, {"user_id": 9650, "stars": [], "topic_id": 7489, "date_created": 1298241846.211638, "message": "@zvikico James Bennett doesn't like it: http://tinyurl.com/6ago56y To me, it feels like monkey patching.", "group_id": 81, "id": 154998}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298244021.5732181, "message": "@ptone http://blog.coderanger.net/2011/02/lazy-profile-middleware/", "group_id": 81, "id": 155120}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298246763.296515, "message": "the add_to_class method looks v. interesting.", "group_id": 81, "id": 155180}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298247247.2630589, "message": "And if, via some miracle, it was a load issue, one call to select_related would have you on your way again.", "group_id": 81, "id": 155196}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298247989.826308, "message": "it's the fact that I'm more or less forced to use someone else's database schema in order to make use of a huge chunk of django's functionality", "group_id": 81, "id": 155226}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298248047.230202, "message": "however, as others seem to not care less about this wart (given that there are no concrete plans to deprecate it) I suppose I should just shut up about it like everyone else", "group_id": 81, "id": 155229}, {"user_id": 1736, "stars": [{"date_created": 1298247165.6249721, "user_id": 719}], "topic_id": 7489, "date_created": 1298247047.8690159, "message": "@danjac You still haven't made it clear why you dislike get_profile() other than complaining about performing extra queries (even when it is clearly unlikely to be a source of problematic load even on a big site).", "group_id": 81, "id": 155191}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249119.410995, "message": "(names are still an issue, as I said earlier)", "group_id": 81, "id": 155330}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298246814.206115, "message": "It may be monkeypatching but django's poor design choices here leave few good options.", "group_id": 81, "id": 155183}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298247933.4811089, "message": "@coderanger: it's poor design, probably resulting from pre-inheritance days. Performance is one issue, but not the most important consideration.", "group_id": 81, "id": 155222}, {"user_id": 719, "stars": [], "topic_id": 7489, "date_created": 1298248229.7864411, "message": "I'd agree it's a wart, but it's a wart with reasonable workarounds. It's also a wart that fixing, while maintaining backwards compatibility, would probably require significant effort. --potential vipers' nest--", "group_id": 81, "id": 155251}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298248258.2940021, "message": "@danjac So you just don't like that your \"user data\" is in a table called \"userprofile\" instead of \"user\"? The default user model is pretty minimal, so I can't imagine you would really want to remove much from it (though I will grant that first and last name fields are not always useful if you have to write for certain cultures). There needs to be some way for multiple unrelated apps to have a common way to refer to a user no matter what, and even if that isn't a DB model anymore I doubt the API would change that much.", "group_id": 81, "id": 155256}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298248352.219521, "message": "@coderanger: fair enough, here's a concrete client requirement - we don't want usernames, just email and first/last names. No username required. Oops, auth.User doesn't like that.", "group_id": 81, "id": 155261}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249066.527848, "message": "Or to put it another way, what fields are pluggable apps allowed to assume exist on User. If there was some other way to swap out User, but all the awesome apps assume there was a .name field it wouldn't put you in a better place.", "group_id": 81, "id": 155326}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249257.9514029, "message": "(also I just checked, first_name and last_name are optional, and so is email)", "group_id": 81, "id": 155350}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249639.695056, "message": "You could also just use uuid.uuid4() as the username and never care about it.", "group_id": 81, "id": 155387}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298248382.283464, "message": "so ultimately, the solution is as you say, we need a way of decoupling foreign keys", "group_id": 81, "id": 155268}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298249221.3510849, "message": "something like 'user=LateBindingForeignKey(\"user\")'", "group_id": 81, "id": 155347}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298249234.6657569, "message": "then you define the value of 'user' in your settings somehow", "group_id": 81, "id": 155349}, {"user_id": 13355, "stars": [], "topic_id": 7489, "date_created": 1298249492.600086, "message": "that results in having the email address in the db twice though.", "group_id": 81, "id": 155371}, {"user_id": 13355, "stars": [], "topic_id": 7489, "date_created": 1298249817.9355669, "message": "Yea, if you don't need \"login with e-mail and password\" that's a better way to do it.", "group_id": 81, "id": 155398}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249006.7084241, "message": "@danjac The issue is that if a user does have a username, there does need to be a common API for getting it. This can be done through different models with the same fields or similar, but that is far more hacky than the current system. It seems like your issue isn't so much lack of ways to customize User, but that the default User (and therefore Django itself) has set the bar incorrect as far as what is the minimum amount of data a user needs to have.", "group_id": 81, "id": 155324}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249104.205879, "message": "That will keep all the 3rd-party apps happy, while not breaking your requirements.", "group_id": 81, "id": 155329}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249091.9608431, "message": "As for you specific case, why can't you pass in the email as the username?", "group_id": 81, "id": 155327}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249281.9581831, "message": "In fact the only field on User that isn't automated or optional is username", "group_id": 81, "id": 155353}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249361.776227, "message": "@danjac How does that help with establishing what fields are fair game for 3rd-party code?", "group_id": 81, "id": 155360}, {"user_id": 13355, "stars": [], "topic_id": 7489, "date_created": 1298249476.4107039, "message": "@danjac for the client you mentioned, you can use an e-mail address as the username, having.", "group_id": 81, "id": 155370}, {"user_id": 1736, "stars": [], "topic_id": 7489, "date_created": 1298249780.50668, "message": "(I've done that before on sites where people could either register locally or use Twitter/FB/OpenID/etc)", "group_id": 81, "id": 155395}, {"user_id": 12747, "stars": [{"date_created": 1298260811.7461729, "user_id": 1081}, {"date_created": 1298283192.7798879, "user_id": 13589}], "topic_id": 7489, "date_created": 1298257393.0752511, "message": "One thing that I've seen others do is to write a custom authentication backend (there's a git package that implements it called EmailAuth).  I think the proper solution is to have the auth module defer to the authentication backend for this...Then, if the authentication backend can be subclassed for a simple method which defines the username, then that would work and perhaps third party apps would never have to know about it.  Unless this makes it into the core though, implementation would require monkeypatching the auth module....This is the direction I'm currently leaning....For anyone who's done this, why is it such an insanely bad idea?", "group_id": 81, "id": 155807}, {"user_id": 12747, "stars": [], "topic_id": 7489, "date_created": 1298257190.3831611, "message": "Actually, logging in with an email address in the username will not work--while 1.2 has allowed more characters into the username, the length is still too short (30 characters), compared to a possible 255 according to RFC (not to mention the nightmare of IDNS).  Now, I suppose that one could use a random number and a hash of the system time to generate a 'username' for django that the actual user never sees....(which I guess would be the same flavor as the uuid.uuid4() approach).    The difficulty is 3rd party apps.", "group_id": 81, "id": 155786}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298271698.7617769, "message": "I've gone down the custom auth backend route as well. It's not a huge burden if you just want to use a custom User class (and have the admin app on a separate install). You just lose the 3rd party apps that depend on contrib.auth.", "group_id": 81, "id": 156988}, {"user_id": 9650, "stars": [], "topic_id": 7489, "date_created": 1298273963.2983849, "message": "We have at least three apps in our project with their own \"UserDetails\".  (BTW, this also means that we cannot use get_profile.  I consider it harmful anyway.)  A ModelDetails model with a O2O relationship is the only way so that different apps can add their own extensions to a certain pre-existing model.", "group_id": 81, "id": 157094}, {"user_id": 9650, "stars": [], "topic_id": 7489, "date_created": 1298274201.333904, "message": "... in a safe way, at least.", "group_id": 81, "id": 157113}, {"user_id": 12914, "stars": [], "topic_id": 7489, "date_created": 1298276290.8131621, "message": "Three more links that can help on the user model customization:     http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users, http://www.djangobook.com/en/1.0/chapter12/#cn222, http://stackoverflow.com/questions/44109/extending-the-user-model-with-custom-fields-in-django", "group_id": 81, "id": 157166}, {"user_id": 3354, "stars": [], "topic_id": 7489, "date_created": 1298280159.486495, "message": "Sounds like a potentially useful addition, though", "group_id": 81, "id": 157315}, {"user_id": 9650, "stars": [], "topic_id": 7489, "date_created": 1298282588.7590699, "message": "@holdenweb Which method would you propose?", "group_id": 81, "id": 157514}, {"user_id": 13589, "stars": [{"date_created": 1298310483.547122, "user_id": 2588}], "topic_id": 7489, "date_created": 1298283331.5997641, "message": "I've been using the random username and custom backend for a couple of years now. Using a custom AuthenticationForm in the mix allows you to change the username field to be an EmailField instead of a CharField, so you can make sure emails are valid as well.", "group_id": 81, "id": 157592}, {"user_id": 13589, "stars": [{"date_created": 1298310477.639251, "user_id": 2588}], "topic_id": 7489, "date_created": 1298283408.03578, "message": "So in all, I think while the User class can be bothersome, it isn't something I intend to worry about much for a while - I know it's limits (they are well documented) and I get on with building around it.", "group_id": 81, "id": 157612}, {"user_id": 214, "stars": [{"date_created": 1298310490.5250151, "user_id": 2588}], "topic_id": 7489, "date_created": 1298301672.699542, "message": "I agree with @danjac that the User model is a legacy remnant that has fields it shouldn't have and is insufficiently flexible - though the question \"what User interface should a third-party app be able to assume\" doesn't have an obvious answer, there are tradeoffs...", "group_id": 81, "id": 159310}, {"user_id": 214, "stars": [{"date_created": 1298336265.238632, "user_id": 521}], "topic_id": 7489, "date_created": 1298301562.013067, "message": "FWIW, the actual get_profile() method and AUTH_PROFILE_MODULE setting are not recommended (if they haven't been marked as deprecated yet in the docs, they should be). It's a pointless layer of indirection that can actually introduce query inefficiencies that could be avoided with standard ORM methods. A UserProfile or equivalent model with a OneToOneField to User is still the recommended way to store additional user details; just use the normal ORM methods to access it instead.", "group_id": 81, "id": 159304}, {"user_id": 4893, "stars": [], "topic_id": 7489, "date_created": 1298303319.1622651, "message": "Every time I think about it, I always want to try just storing the extra fields in redis and use a proxy model ;-)", "group_id": 81, "id": 159480}, {"user_id": 7364, "stars": [], "topic_id": 7489, "date_created": 1298305816.061826, "message": "@carljim: where does it say that get_profile() is not recommended ? All the literature I've read pretty much points to that as the \"standard\" way of customizing your user model.", "group_id": 81, "id": 159604}, {"user_id": 960, "stars": [], "topic_id": 7489, "date_created": 1298310447.2843649, "message": "@danjac Documentation doesn't always keep up with standard practice.  There's no need to have a `get_profile()` with reverse relationships, it's just never been removed.", "group_id": 81, "id": 160243}, {"user_id": 214, "stars": [], "topic_id": 7489, "date_created": 1298312644.214484, "message": "@danjac It's been discussed on the django-developers mailing list various times. I recall more than one core developer agreeing that it shouldn't be recommended, though I don't think there was consensus, which probably explains why the docs haven't changed...", "group_id": 81, "id": 160595}, {"user_id": 35368, "stars": [{"date_created": 1307376120.585484, "user_id": 35368}], "topic_id": 7489, "date_created": 1307376110.6079471, "message": "I just want to increse username field size 30 to 75. so how do i achieve this issue?", "group_id": 81, "id": 1305262}, {"user_id": 35368, "stars": [{"date_created": 1307376123.113235, "user_id": 35368}], "topic_id": 7489, "date_created": 1307375931.1221759, "message": "Hey can anyone help me on customizing user model in django", "group_id": 81, "id": 1305218}, {"user_id": 3354, "stars": [], "topic_id": 7489, "date_created": 1307394447.7519059, "message": "First, you will need to change the field length in your database. Then change the field length in your model definition. You may need you DBA's assistance with step 1.", "group_id": 81, "id": 1311558}, {"user_id": 12030, "stars": [{"date_created": 1307967539.8572879, "user_id": 5778}], "topic_id": 7489, "date_created": 1307548227.284812, "message": "@akshay the best way I've found to do this is with South. I usually have a \"common\" app in my projects which is where I put this migration. I create an empty migration with South and have it change the username varchar length. This way it handles it during deployments as well. The migration is an easy one liner you'll need to write for the up and down methods.", "group_id": 81, "id": 1338617}]