I made this in response to Jacob's original proposal, which I understand to have been scrapped in favor of Adrian's (which doesn't have user.data at all, thankfully). Therefore, I believe my point below is now moot.
For the record, I am much more excited about Adrian's proposal (no offense, Jacob :)). I was convinced that profiles was the only way to go when I read Jacob's proposal, but it sounds like there is a mechanism to make swappable User models work, which is much more in tune with how I use Django. Profiles, to me, are ugly. At best. Regards, Luke On April 4, 2012, at 15:28 , Daniel Sokolowski wrote: > I agree with Luke that more explicit is better then implicit when dealing > with the user.data. > > From: Luke Sneeringer > Sent: Tuesday, April 03, 2012 2:46 PM > To: django-developers@googlegroups.com > Subject: Re: auth.user refactor: the profile aproach > > So, after reading this, I think I really only have a couple > questions/concerns: > > 1. What, if anything, is the primary key on the base User model? Is it the > identifier? If so, can it be specified as the primary key, rather than > unique=True, db_index=True? If it's not the primary key, is it the usual > magical id = models.AutoField()? > > 2. I'm a little nervous about the magical installation of Profile modules -- > specifically, what happens once this system has been around for one to two > years and we have a ton of these? I'm imagining a situation where there are > lots of apps floating around, each with their own Profile subclasses that > install behind the scenes when you install the app (and which you may or may > not actually realize up front -- yes, a good developer *should* be aware of > that, but that doesn't mean they will be...). What happens if a beginner > writes everything against user.data['name'], and then installs an app that > adds a new name, which is unordered and magically ends up on top, and > therefore introduces new, unexpected, and, most importantly, extremely > difficult to debug logic errors? > > I agree with some of the criticisms of swappable user models, but at least > the developer always knows what he is doing in that case. In this case, the > behavior of your user model can change in unexpected ways when you do > something that seems totally unrelated; some code that previously worked > might either (1) return different data or (2) suddenly raise KeyError. > > Perhaps this is the best of bad options. I agree there's a decent bit to be > argued in favor of it, but can we figure out a less error-prone way for > user.data to work? Honestly, I think it would be less risky to force everyone > to write user.admin_profile.name -- it's more typing, but at least it's > explicit. The current proposal for user.data doesn't actually pass "refuse > the temptation to guess", because it glosses over the fact that developers > *will guess* and then their code will stop working after what feels like a > completely unrelated change. > > 3. Might I suggest that the Profile model that the admin requires be called > AdminProfile and not DefaultProfile? It's really an admin need more than > anything else. > > > Best Regard, > Luke -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
