Tom, Thanks for raising those issues. I would just like to add that I hope to see fields currently in `User` that are required by the admin (is_staff, etc.), moved to an admin profile model, and not simply made available through mixins that are still required by every `User` model that gets swapped in.
Even if we technically allow the `User` model to be swapped in, and therefore allow new fields to be added to it, I think that this would set a dangerous example and precedent for authors of other pluggable apps. The admin is arguably *the* premiere example of a "pluggable" app, held up as a reference on how it should be done. I think it's important that we clearly define when it is appropriate for a pluggable app to require schema changes to a project's `User` model, and that should only be in rare and specific circumstances. Generally, fields should only be added to the `User` model by a project author (not a pluggable app author), because pluggable app authors won't know the details of the environment (other pluggable apps and project) they will be installed into. I also hope to see a more fleshed out proposal from Adrian, before an actual implementation is delivered, hopefully containing answers to some of the questions raised here. Cheers. Tai. On 10/04/2012, at 7:47 PM, Tom Evans 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.
