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.
