I think swappable user models should be used as a replacement for get_profile() not per app profiles.
It should be used for generic-esque data about a User. e.g. Email, phone number, name, etc. It should not be used for app specific data about a user, e.g. Default Gallery, Notification Settings, etc. On Tuesday, April 10, 2012 at 6:01 PM, Tai Lee wrote: > Alex, > > I think the problem with this aspect of your proposal is that it signals a > green light for other pluggable apps to follow Django's lead and provide > mixing which must be added to their `User` model in order to use the > pluggable app, instead of creating a profile model for their pluggable app. > > Django's admin is a pluggable app, and it should follow the best practices > that we recommend for authors of other pluggable apps. > > It has been suggested that "nothing is stopping pluggable app authors from > continuing to use profiles", but on the flip side, nothing is going to stop > them from using mixins and requiring a schema migration to install their > pluggable app. > > If we allow swappable models, we should strongly recommend (in documentation, > and by example with the admin) that pluggable app authors continue to use > profiles, and that only project authors use the ability to swap in a new > `User` model for their own purposes, and not to support a pluggable app. > > Cheers. > Tai. > > > On 11/04/2012, at 3:25 AM, Alex Ogier wrote: > > Tom, > > I proposed mixins to solve the specific problem: there is an app that needs > > a specific contract from a model it wants to authenticate or otherwise > > interact with, how can we make it easy for developers to implement that > > contract? > > Most apps don't actually need that much though. There are a bunch of > > standard ways to relate to a model that don't invasively change it. They > > are all still available, and in fact preferred because no matter how easy > > it is to use a mixin, doing nothing is even easier. > > Best, > > Alex Ogier > > On Apr 10, 2012 10:58 AM, "Tom Evans" <tevans...@googlemail.com > > (mailto:tevans...@googlemail.com)> wrote: > > > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis <ianmle...@gmail.com > > > (mailto:ianmle...@gmail.com)> wrote: > > > > Hi, > > > > > > > > I'm not getting why you *have* to add fields to the User model to store > > > > data > > > > pertaining to the user. There is nothing in the proposal for pluggable > > > > user > > > > models that says you can never have a seperate model with a foreign key > > > > to > > > > the user model. It just means that you can define your user model the > > > > way > > > > you want it to be. > > > > > > That is perfectly fine. The problem comes when there is a simple > > > system to add fields to the user model, people will use it to add > > > fields to the user model in their pluggable apps, for 'simplicity' and > > > 'ease of use'. > > > > > > > Why can't third party apps have a model with a foreign key to the user > > > > table > > > > with the pluggable models approach? I imagine you are right that every > > > > app > > > > and it's brother adding fields to the user model is not realistic but I > > > > don't think that anyone has proposed that. Certainly not me. > > > > > > The proposed solution as decided by BDFL diktat is 2a from [1]. I quote: > > > > > > Split off as much as possible of auth.User into orthogonal mixins that > > > can be reused. > > > Modify auth.User to inherit these mixins. Care must be taken to ensure > > > that the database expression of the new User model is identical to the > > > old User model, to ensure backwards compatibility. > > > Unrelated and third-party apps can indicate that they depend on > > > various orthogonal mixins. For example, contrib.admin can specify that > > > it works with auth.User out of the box, and with any model > > > implementing PermissionsMixin if you supply your own login forms. > > > > > > At the moment, you cannot change the user model, so we do not have > > > issues relating to third party apps changing the user model. With the > > > proposed solution, you would be able to change the user model, so we > > > may have issues. > > > > > > It's also enlightening to read the code from Alex's Django branch, > > > which is an initial implementation of option 2a. > > > > > > > The thing I > > > > want to be able to is define user models suitable for my project. Third > > > > party apps adding their own fields wasn't proposed by anyone AFAIK, nor > > > > was > > > > specifically requiring that you add them yourself. Some might require > > > > that > > > > your user has something like an 'email' field because that would be a > > > > common > > > > field across apps but app specific data can easily go on a seperate > > > > model > > > > included with the app that simply has a FK to user. You can then only > > > > fetch > > > > that data on requests that need it. > > > > > > > > I'm sorry but doing a JOIN every request is a BAD idea. You will run > > > > into > > > > problems there quickly and have no way out of it besides ditching auth > > > > completely (and thus all the thirdparty apps you use that depend on it). > > > > > > I completely disagree, but I'm not here to try and convince people how > > > to design their databases. A JOIN every request will not end the > > > world. Besides, it is far more likely to be a separate query than a > > > JOIN, and would only happen on views that required that data. > > > > > > More to the point, what basis are you making this claim on? People > > > love to pipe up "JOINs are slow and evil", but have you actually > > > analysed the cost compared to monolithic tables? > > > > > > > Assuming the user table and profile tables are small is awfully short > > > > sighted. > > > > > > To be fair, I was slightly ambiguous with my use of the word 'small'. I > > > said: > > > > > > >> Queries against monolithic tables are much slower than a few queries > > > >> on much > > > >> smaller tables. > > > > > > Here 'small' means fewer columns, not less tuples. > > > > > > However, assuming tables will be small is precisely what you have just > > > done - "we must not have JOINs, they are evil, but it doesn't matter > > > because the user table will only have the columns I desire". I agree > > > that it is a short sighted position, if you do not prevent the table > > > becoming monolithic ;) > > > > > > > > > Cheers > > > > > > Tom > > > > > > [1] https://code.djangoproject.com/wiki/ContribAuthImprovements > > > > > > -- > > > 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 > > > (mailto:django-developers@googlegroups.com). > > > To unsubscribe from this group, send email to > > > django-developers+unsubscr...@googlegroups.com > > > (mailto:django-developers%2bunsubscr...@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 > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto: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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto: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.
