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> wrote: >>>> On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis <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. >>>> 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. >> >> >> -- >> 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. -- 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.
