Sorry I was mentioning that in agreement with documenting this. I had even toyed with the idea of making the default template provide a project level user model by default (to cement the fact that it's project concern not a app concern) but that is most likely more trouble than it's worth.
On Tuesday, April 10, 2012 at 6:34 PM, Tai Lee wrote: > Sure. But will how will users be guided to making that distinction when > developing their pluggable apps? I haven't seen anything that would prevent > developers from doing this, and if the admin itself does it, isn't that a > green light for everyone to do it? > > Another problem with pluggable apps (like the admin) adding fields to the > `User` model is that they make an assumption that *every* user is a user of > that particular pluggable app. > > I use the admin, but not *every* user has access to the admin. Those users > shouldn't need to have values (even default values, e.g. is_staff=False) for > admin-specific fields, and admin-specific fields shouldn't be selected every > time any user is retrieved from the database. > > Cheers. > Tai. > > > On 11/04/2012, at 8:05 AM, Donald Stufft wrote: > > 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 > > (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.
