Hi Tom,
The best rounded description with pros and cons is Solution 2a on
https://code.djangoproject.com/wiki/ContribAuthImprovements
You are correct that I am primarily thinking of pluggable authentication
when I think of this new user model. The reason is that there is nothing
stopping you from continuing to place app data outside the user model as
has been standard for a while now. For example, there is nothing stopping
you from using the following pattern in you app's view:
if request.user.is_authenticated():
try:
prefs = GalleryPref.objects.get(user=request.user)
except GalleryPref.DoesNotExist:
prefs = None
That is, unless you have a reason that your particular data should be
eagerly loaded on every request there is no reason to require it on the
user. In fact app developers are incentivized to keep their data separate
in order to remain compatible with the default user.
The solution isn't perfect, it does in fact provide some barriers to this
pattern. The Gallery app must explicitly choose to foreign key to
settings.USER_MODEL, and once they do *changing* which model the setting
points to requires a migration of your table. These are both real issues,
but I don't think that user model bloat will be because there is a
straightforward way to work around it if it does prove to be an issue for
any particular project.
The only thing this proposal kills is magic proxying back from user
attributes. If you really wanted to, you could roll your own proxy
attributes to app fields, after all you control the entire user class.
Best,
Alex Ogier
On Apr 10, 2012 5:47 AM, "Tom Evans" <tevans...@googlemail.com> wrote:
> On Fri, Apr 6, 2012 at 7:31 PM, Alex Ogier <alex.og...@gmail.com> wrote:
> > Tai, read https://gist.github.com/2289395 for a summary of many reasons
> why
> > I think profiles are a bad idea, and unifying multiple profiles is an
> even
> > worse idea.
> >
> > Best,
> > Alex Ogier
>
> Hi Alex
>
> Is https://gist.github.com/2289395 the complete proposal for what is
> to be implemented? It seems more of a point by point rebuttal of
> another proposal.
>
> Is the approved solution to have mixins which contribute to a user
> class? Are pluggable apps expected to provide mixins that contribute
> to the user model?
>
> Does this proposal fix the current issues with the user model in new
> projects?
>
> My biggest concerns with this approach:
>
> 1) Monolithic user tables.
>
> Adding apps that want their own user storage with this system requires
> new columns in your user model. This is not the best approach. Foreign
> keys to separate user data tables per app is much more appropriate.
>
> Monolithic tables kill performance. As an example, a C++ ORM I have
> used had this approach, and it was common to come across a user table
> with 100+ columns, including some massive fields (unbounded text
> fields, blobs). On most page requests, only a few columns were looked
> at, but every page paid the cost of retrieving massive user objects.
>
> The most common complaint against profiles is that they are 'slow' as
> you have to join to many tables, or issue multiple queries. Queries
> against monolithic tables are much slower than a few queries on much
> smaller tables.
>
> 2) Constant flux on my user model as a site develops
>
> Adding new apps which require user storage would require schema
> change. If you have lots of users, this is a real pain. When adding an
> app profile, all that is required is a new table to be created, which
> would not lock a critical table like 'user' for a long period.
>
>
> I've no objection to allowing project managers more control over the
> user model, but I don't think we should encourage the majority of
> pluggable apps to pollute the user model - in fact, probably only apps
> dealing with AAA.
>
> Eg, a photo gallery app may want to store the preferred thumbnail size
> and whether to open images in a new window. These do not belong on the
> user model, but on a photo gallery app profile. Most users may not
> have preferences, and for those that do, it is only relevant to access
> that info on a photo gallery page.
>
> A twitter auth app may want to store an oauth token. This should
> belong on the user model, as it is used for AAA, and may be accessed
> on any request.
>
> Cheers
>
> Tom
>
> --
> 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.
>
>
--
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.
