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.
